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Abstract 

This  thesis  presents  a  derivation  of  an  efficient  rule  system  pattern  matcher.  The  matcher 
efficiently  computes  all  matches  between  a  set  of  rules  and  a  database.  The  rules  may 
have  multiple  patterns.  The  matcher  incrementally  updates  the  set  of  matches  as  changes 
are  made  to  the  database.  This  matcher  is  modeled  on  the  Rete  matcher  used  in  the 
popular  0PS5  production  system. 

The  representations  used  in  the  matcher  are  modeled  on  the  structures  used  in  the 
model-theoretic  semantics  of  first-order  logic.  This  thesis  demonstrates  the  correspon¬ 
dence  between  these  structures  and  the  data  structures  used  in  the  Rete  matcher.  A  new 
structure,  the  lattice  of  disjunctive  substitutions,  is  introduced  to  capture  the  semantics 
of  the  rule-system  matching  computation.  An  element  of  this  lattice  represents  the  set 
of  all  matches  between  a  rule  and  the  terms  in  a  database. 

The  derivation  is  implemented  using  program  transformations.  First,  a  formal  spec¬ 
ification  is  developed.  Then  transformations  are  apphed  to  this  specification  to  derive 
an  initial  implementation.  Finally,  other  transformations  are  applied  to  derive  more  ef¬ 
ficient  implementations  from  the  initial  implementation.  The  main  technique  used  for 
improving  efficiency  is  finite  differencing.  This  optimization  can  be  shown  to  arise  from 
distributive  laws  involving  operations  on  the  disjunctive  substitution  lattice. 

The  derivation  has  been  implemented  using  a  wide-spectrum  language  and  an  inter¬ 
active  program  transformation  system. 

This  work  is  presented  as  a  contribution  towards  the  construction  of  a  library  of 
programming  knowledge  to  facilitate  software  reuse  and  automatic  programming.  In 
particular,  future  directions  are  described  for  research  towards  a  library  of  p’-jgramming 
knowledge  for  implementing  rule  systems. 
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Chapter  1 


Introduction 


The  first  section  of  this  chapter  presents  background  and  motivation  for  this  research. 
The  second  section  presents  a  brief  overview  of  the  thesis. 


1,1  Background 

Programs  are  still  written,  and  rewritten,  in  a  manual,  ad-hoc  manner.  A  goal  of  auto¬ 
matic  programming  research  is  to  foster  an  alternative  approach  to  programming.  This 
approach  involves  gathering,  organizing,  formalizing  and  implementing  programming 
knowledge.  Researchers  have  begun  to  use  this  approach  to  automate  the  development 
of  small  programs.' 

We  would  like  to  build  a  library  of  programming  knowledge  that  embodies  the  com¬ 
mon  collection  of  algorithms,  data  structures,  and  techniques  that  are  the  basis  of  pro¬ 
gramming.  Our  main  objective  is  to  use  this  library  to  build  automatic  programming 
systems.  A  second  benefit  that  accrues  from  this  approach  is  that  we  develop  sharper 
understandings  of  current  algorithms  and  techniques.  This  thesis  is  intended  as  a  con¬ 
tribution  towards  both  of  these  goals.  As  such,  it  should  be  of  interest  both  to  readers 

emphasize  that  this  approach  currently  works  with  small  programs  because  it  does  not  directly  ad¬ 
dress  the  complexity  management  issues  that  arise,  and  dominate,  programming-in-the-large.  However, 
automating  programming-in-the-small  could  be  of  enormous  value  to  all  programmers. 
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interested  in  automatic  programming,  and  to  readers  interested  in  the  particular  appli¬ 
cation  domain  that  I  have  studied. 

The  application  domain  that  I  have  focused  on  is  Artificial  Intelligence  programming. 
Specifically,  I  have  focused  on  rule  systems,  which  are  one  of  the  most  important  types 
of  programs  in  AI.  I  use  the  term  rule  system  to  encompaiss  all  systems  derived  from 
the  paradigm  of  logical  inference.  These  include  production  systems,  theorem  proving 
systems,  and  deductive  databases. 

I  consider  the  basic  task  of  efficiently  implementing  a  rule  system.  The  core  of  this 
task  involves  efficiently  finding  all  matches  between  the  rules  and  the  data.  The  algo¬ 
rithm  derived  is  modeled  on  the  Rete  matcher  [11]  used  in  the  OPS5  Production  System 
[5].  This  matcher  efficiently  finds  all  matches  for  a  rulebase  and  a  database,  and  then 
incrementally  updates  this  set  of  matches  as  the  database  is  modified. 

The  heart  of  the  derivation  is  a  mathematical  model  of  the  information  computed  and 
manipulated  in  performing  this  task.  The  representations  used  in  the  final  program  are 
derived  directly  from  this  model.  The  structures  in  this  model  are  similar  to  the  structures 
used  in  the  model-theoretic  semantics  of  first-order  logic.  One  of  the  contributions  of 
this  thesis  is  an  explicit  description  of  this  connection  between  the  structures  computed 
in  the  Rete  network  and  the  valuation  structures  of  model  theory. 

There  have  been  several  papers  published  on  formal  models  of  rule  systems,  e.g. 
[27].  However,  my  attempt  to  formalize  the  structures  in  the  Rete  matcher  has  led 
me  to  introduce  an  extension  to  the  published  formal  models.  Specifically,  I  introduce 
disjunctive  substitutions  to  represent  the  information  obtained  from  matching  a  pattern 
against  several  possible  data  in  a  database.  The  formal  derivation  of  the  matcher  is 
based  on  a  homomorphism  from  the  matcher  specification  to  a  lattice  formed  from  these 
disjunctive  substitutions. 

This  mathematical  model  leads  to  an  initial  algorithm  that  satisfies  the  functional 
specification  for  the  matcher,  but  does  not  satisfy  the  performance  requirements.  How¬ 
ever,  by  application  of  the  general  purpose  techniques  of  finite  differencing  [19]  and  partial 
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evaluation  [15],  this  initial  implementation  can  be  transformed  into  an  algorithm  similar 
to  the  Rete  matcher.  The  result  of  this  work  can  therefore  be  expressed  schematically  as 

Rete  =  Formal  Specification 

+  Lattice  Construction  based  on  Homomorphism  to  Specification 
+  Finite  Differencing  based  on  Distributive  Laws 
+  Partial  Evaluation. 

Though  the  heart  of  this  thesis  is  a  formal  derivation,  I  also  present  an  implemen¬ 
tation  of  the  derivation.  The  technology  used  for  this  implementation  consists  of  a 
wide-spectrum  specification  language,  and  an  interactive  transformational  development 
system.  Specifically,  I  have  used  the  Refine^  language[21],  and  the  Kestrel  Interactive  De¬ 
velopment  System  (KIDS)[31].  However,  the  derivation  is  independent  of  these  systems, 
and  could  easily  be  re-implemented  in  another  system. 

This  thesis  also  discusses  some  future  directions  for  program  transformation  systems, 
and  some  future  directions  towards  implementing  a  comprehensive  library  of  program¬ 
ming  knowledge  for  implementing  rule  systems. 

1.2  Thesis  Roadmap 

This  section  outlines  the  contents  of  each  of  the  remaining  chapters. 

Chapter  2  introduces  rule  systems,  and  describes  the  Rete  algorithm  in  detail.  It  also 
describes  the  simplifications  made  in  this  thesis,  i.e.  the  differences  between  the  Rete 
matcher  and  the  matcher  derived  in  this  thesis. 

Chapter  3  presents  the  derivation  of  the  initial  (unoptimized)  version  of  the  matcher. 
The  core  of  this  derivation  involves  an  algebraic  construction  of  a  lattice  of  sets  of  sub¬ 
stitutions  representing  the  matches  between  patterns  and  sets  of  data. 

^Refine  is  a  trademark  of  Reasoning  Systems,  Inc.,  Palo  Alto,  CA 
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Chapter  4  describes  the  correspondence  between  the  matcher  derived  in  Chapter  3 
and  the  Rete  matcher,  and  describes  the  optimizations  that  improve  the  efficiency  of  the 
initial  matcher  so  that  it  is  comparable  to  the  Rete  matcher. 

Chapter  5  describes  the  (partial)  implementation  of  this  derivation  using  the  Refine 
wide-spectrum  language  and  the  KIDS  transformational  development  system. 

Chapter  6  presents  a  discussion  of  the  derivation.  It  explores  the  relationship  between 
the  structures  used  in  the  derivation  and  the  structures  used  in  model-theoretic  seman¬ 
tics,  discusses  the  status  of  the  implementation,  outlines  directions  for  future  research, 
surveys  the  related  literature  and  explains  the  contribution  of  this  thesis  to  the  literature, 
and  summarizes  the  conclusions  of  the  thesis. 

The  appendix  contains  brief  tutorial  material  on  algebraic  structures,  lattice  theory, 
and  model-theoretic  semantics. 
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Chapter  2 


Rule  Systems  and  Rete 


This  chapter  presents  an  informal  description  of  rule  systems  in  general,  and  of  the  Rete 
algorithm  in  particular.  It  also  describes  the  simplifications  that  have  been  made  in 
this  thesis,  i.e.  the  features  of  the  Rete  matcher  that  have  been  left  out  of  the  matcher 
derived  in  Chapters  3  and  4.  Chapter  3  begins  by  formalizing  the  rule  system  description, 
and  proceeds  with  the  formal  derivation.  Chapter  4  returns  to  this  description  of  the 
Rete  algorithm  in  order  to  show  the  correspondence  between  the  algorithm  derived  in 
Chapters  3  and  4,  and  the  Rete  algorithm. 


2.1  Rule  System  Introduction 

A  rule  system  contains  two  main  data  structures:  a  database  (db),  and  a  rulebase  (rb). 
For  our  purposes,  the  data  in  the  database  can  be  considered  to  be  arbitrary  Lisp  s- 
expressions.  The  rules  in  the  rulebase  are  structures  consisting  of  two  fields:  the  Left 
Hand  Side  (LHS),  and  the  Right  Hand  Side  (RHS).  The  rules  are  modeled  on  the  inference 
rules  in  a  logical  system.  The  LHS  of  a  rule  consists  of  a  set  of  patterns,  which  are  s- 
expressions  containing  variables.  A  pattern  from  an  LHS  can  be  matched  against  a  datum 
in  the  database  by  finding  a  substitution  that  replaces  the  variables  in  the  pattern  by 
terms  so  that  the  resulting  pattern  is  equal  to  the  datum.  The  LHS  of  a  rule  can 


14 


be  matched  against  the  database  by  finding  a  single  substitution  under  which  each  of 
the  patterns  in  the  LHS  matches  some  datum  in  the  database.  If  such  a  substitution 
exists,  the  rule  is  applicable  to  the  database.  For  a  given  database  and  rulebase,  several 
rules  might  be  applicable,  and  the  same  rule  might  be  applicable  with  several  different 
substitutions.  The  set  of  pairs  of  applicable  rules  and  corresponding  substitutions  is 
called  the  conflict  set} 

A  rule  can  be  applied  in  the  forward  direction  by  matching  the  LHS  of  the  rule 
against  the  database,  and  then  instantiating  the  RHS  of  the  rule  with  the  substitution 
that  resulted  from  the  matching,  and  adding  the  result  to  the  database.  On  each  cycle 
of  a  rule  system,  the  system  computes  the  conflict  set,  invokes  the  conflict  resolution 
procedure  to  select  a  single  rule-substitution  pair  from  the  conflict  set,  and  applies  that 
rule  to  the  database.  The  interpreter  repeats  this  cycle  of  operations  until  a  specified 
termination  condition  is  satisfied.  In  this  thesis  I  am  not  concerned  with  the  termination 
condition,  so  I  will  simply  assume  that  the  rule  system  continues  until  the  conflict  set  is 
empty. 

This  rule-system  operation  is  summarized  by  the  code  in  Figure  2-1.  This  specifica¬ 
tion  describes  the  operation  of  a  forward-chaining  rule  system.  It  is  written  in  an  informal 
notation  that  is  intended  to  combine  the  features  of  an  Algol-like  high  level  programming 
language,  with  additional  mathematical  notation  not  usually  present  in  a  programming 
language.  (One  example  of  the  added  notation  is  a  set-former,  e.g.  {i  |  /’(x)},  which 
represents  the  set  of  all  elements  x  that  satisfy  the  predicate  P.)  In  Chapter  5  this 
specification  is  implemented  in  the  Refine  wide-spectrum  language. 

In  this  specification  there  are  three  data  structures:  db  (the  database),  rb  (the  rule- 
base),  and  cs  (the  conflict  set).  Lines  2  and  6  specify  that  the  code  on  lines  3-5  are 
repeated  on  each  cycle  of  the  interpreter.  Lines  3  and  9  state  that  cs  is  assigned  the 

^The  terms  conflict  set  and  conflict  resolution  are  taken  from  the  domain  of  production  systems. 
(The  Rete  algorithm  was  first  implemented  in  the  OPS5  production  system.)  In  these  systems  the  order 
in  which  rules  are  run  is  critical  to  the  proper  operation  of  the  system.  If  several  rules  are  applicable  in 
a  given  state,  the  rules  are  said  to  be  in  conflict,  and  a  special  procedure  is  called  to  resolve  this  conflict 
and  select  which  rule  to  run. 
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1  function  v\i[e-system{db,rb)  = 

2  repeat 

3  cs  *—  {{r,cr)  \  r  £  rb  A  cr  €  match-rule(r,  dft) } 

4  (r,  cr)  *—  conflict-resolution(cs) 

5  <i6  U  {(r/i5(r))''} 

6  until  cs  =  0  • 

7  return((i6) 

8  end  function 

9  function  match-rule(r,  <i6)  =  Rep[{<T  |  Vpg  ihs(r)  ^dedb  p'^  —  d]] 

10  end  function 

Figure  2-1:  Rule  System  Specification. 

set  of  all  rule-and-substitution  tuples,  such  that  the  rule  is  in  the  rulebase,  and,  for  all 
patterns  in  the  LHS  of  the  rule,  there  exists  some  datum  in  the  database  such  that  the 
pattern,  when  instantiated  with  the  substitution,  is  equal  to  the  datum.  That  is,  the 
conflict  set  contains  all  rules  that  match  against  the  database,  with  the  corresponding 
substitutions.  (Note  that  a  rule  can  appear  in  the  conflict  set  several  times,  with  several 
different  substitutions.)  On  line  4  the  conflict-resolution  procedure  is  used  to  select  one 
rule-and-substitution  tuple  from  the  conflict  set.  Line  5  instantiates  the  RHS  of  the 
selected  rule  with  the  selected  substitution,  and  adds  the  result  to  the  database. 

Since  the  set  of  substitutions  in  line  9  is  an  infinite  set,  a  representation  function 
(Rep)  is  used  to  denote  a  concrete  representation  of  this  set.  Chapter  3  contains  a  more 
detailed  discussion  of  the  formal  model  underlying  this  specification. 

2.2  Rule  System  Finite  Differencing 

A  direct  implementation  of  the  interpreter  shown  in  Figure  2-1  would  be  correct,  but 
inefficient.  The  major  inefficiency  arises  from  the  recomputation  of  the  conflict  set  on 
each  cycle  of  the  rule  interpreter.  The  computation  of  the  conflict  set  involves  examining 
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all  of  the  data  in  the  database  and  all  of  the  rules  in  the  rulebase.  It  is  usually  the  case 
that  the  database  is  relatively  large  and,  since  only  one  new  element  is  added  to  it  on 
each  cycle,  the  recomputation  of  the  conflict  set  on  each  cycle  is  mostly  unnecessary. 
more  efficient  approach  would  bo  to  compute  the  conflict  set  for  the  initial  database  and 
rulebase,  and  thereafter  to  incrementally  update  the  conflict  set  as  changes  are  made 
to  the  database.^  This  is  the  approach  followed  in  the  Rete  algorithm  [11]  [5].  The 
central  feature  of  this  algorithm  is  that  it  maps  incremental  changes  to  the  database  into 
incremental  changes  to  the  conflict  set. 


2.3  Rete  Description 

The  main  idea  behind  the  Rete  network  is  to  compile  the  rulebase  into  a  token-passing 
dataflow  network  that  incrementally  accepts  changes  to  the  database,  and  produces  cor¬ 
responding  changes  to  the  conflict  set.  This  section  describes  the  simplified  Rete  network 
that  we  will  be  considering.  The  simplifications  are  described  in  Section  2.4. 

Since  the  parts  of  the  Rete  network  generated  by  different  rules  are  basically  inde¬ 
pendent  we  will  concentrate  on  the  Rete  network  for  a  single  rule. 

Figure  2-2  shows  a  Rete  network  for  the  rule 

(  {(/  ?y)}  (p  ?z  ?y)  ). 

A  Rete  network  is  composed  of  three  types  of  nodes: 

•  Match  nodes  (called  1 -input  nodes  in  Rete), 

•  Combine  nodes  (called  2-input  nodes  in  Rete),  and 

•  Rule  nodes  (called  Terminal  nodes  in  Rete). 


2 


VVe  assume  the  rulebase  remains  fixed  during  the  operation  of  the  rule  system. 
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There  are  three  types  of  tokens  passed  between  the  nodes: 

•  Database-Change  Tokens, 

•  Substitution  Tokens,  and 

•  Rule-Substitution  Match  Tokens. 

The  rest  of  this  section  is  a  description  of  the  operation  of  the  Rete  network.  This 
description  is  organized  by  tracing  the  progression  of  a  token  in  the  network.  (Please 
refer  to  Figure  2-2.) 

The  task  of  the  matcher  is  to  accept  database-change  tokens,  and  to  output  the 
corresponding  changes  to  the  conflict  set.  The  changes  to  the  database  are  input  to  the 
network  on  the  bus  at  the  top  of  the  figure. 

Match  Nodes 

The  nodes  at  the  top  of  the  figure,  labelled  (f  ?x),  (g  ?y),  and  (h  ?x  ?y),  represent 
matching  nodes  for  the  various  patterns  in  the  rule.  There  is  one  matching  node  for  each 
pattern  in  the  rule.  (In  the  full  Rete  network  there  would  be  one  matching  node  for  each 
pattern  in  the  rulebase.)  A  match  node  has  a  single  input  port  and  a  single  output  port. 

Copies  of  all  new  data  tokens  entering  on  the  top  bus  are  distributed  to  all  match 
nodes  in  the  network.  A  match  node  processes  a  new  data  token  by  matching  it  against 
the  node’s  pattern.  If  the  datum  and  the  pattern  match,  a  token  containing  the  resulting 
substitution  is  passed  out  of  the  output  node  of  the  match  node.  If  the  datum  and 
pattern  do  not  match,  no  token  is  passed  out  of  the  match  node. 

Combine  Nodes 

Tokens  passed  from  the  output  ports  of  match  nodes  are  sent  to  the  input  ports  of 
combine  nodes.  A  combine  node  has  two  input  ports  referred  to  as  the  left  input  and  the 
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right  input. ^  Each  of  the  input  ports  of  a  combine  node  hats  a  memory  associated  with 
it.  This  memory  holds,  all  of  the  tokens  that  have  been  received  at  that  port  since  the 
network  was  initialized.  A  combine  node  has  a  single  output  port. 

The  role  of  a  combine  node  is  to  combine  the  substitution  tokens  from  its  left  and  right 
parent  nodes  and  to  generate  a  stream  of  substitution  tokens  the  contain  substitution 
that  are  consistent  with  the  substitutions  received  at  its  left  and  right  input  nodes.  Each 
output  substitution  must  be  consistent  with  some  substitution  received  at  the  left  input, 
and  with  some  substitution  received  at  the  right  input. 

The  combine  node  functions  as  follows.  When  a  new  token  is  received  at  the  left 
input  port  of  a  combine  node,  it  is  inserted  into  the  left  input  memory,  and  combined 
with  all  of  the  elements  in  the  right  input  memory  of  the  node.  If  the  results  of  any 
of  these  combinations  are  valid  substitutions,  these  results  are  passed  out  of  the  output 
port  of  the  combine  node. 

The  corresponding  process  is  performed  when  a  token  is  received  at  the  right  input 
port  of  a  combine  node.  The  token  is  inserted  into  the  right  input  memory,  and  combined 
with  all  of  the  tokens  in  the  left  input  memory.  Any  valid  combinations  are  passed  out 
the  output  port. 

Rule  Nodes 

A  fan-in  tree  of  combine  nodes  is  built  up  for  all  of  the  patterns  in  the  LHS  of  a  rule, 
as  shown  in  Figure  2-2.  The  output  port  of  the  final  combine  node  is  connected  to  a 
rule  node.  This  node  accumulates  all  matches  for  this  rule  in  the  current  database.  The 
collection  of  all  of  the  substitution  tokens  stored  in  all  of  the  rule  nodes  in  a  network, 
with  each  substitution  token  paired  with  the  corresponding  rule,  constitutes  the  conflict 
set  for  the  current  database  and  rulebase. 

^The  ports  are  functionally  symmetrical;  these  terms  are  introduced  for  e.xplanatory  purposes. 
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2.4  Simplifications 

In  this  thesis  I  am  interested  in  concentrating  on  the  central  feature  of  the  Rete  algorithm: 
the  computation  of.  the  conflict  set,  and  the  incremental  recomputation  of  this  set  as  the 
database  is  modified.  The  matcher  derived  in  this  thesis  hats  the  same  basic  structure 
as  the  Rete  algorithm,  and  performs  the  same  incremental  update  of  the  conflict  set  as 
does  the  Rete  algorithm.  However,  it  is  a  much  simplified  version  of  the  Rete  algorithm. 
The  following  features  of  Rete  are  not  addressed  in  the  derivation: 

•  In  Rete  rules  can  have  negated  patterns  which  match  if  the  corresponding  positive 
pattern  does  not  match  against  a  datum  in  the  database.  The  matcher  developed 
in  this  thesis  does  not  handle  negated  patterns. 

•  In  Rete  rules  can  delete  data  from  the  database,  as  well  as  adding  data.  In  this 
thesis  we  only  consider  rules  that  add  data  to  the  database. 

•  In  Rete,  the  matching  for  a  pattern  that  appears  in  several  rules  is  shared  between 
rules.  This  capability  is  not  implemented  in  this  thesis. 

This  section  briefly  discusses  these  features. 

The  Rete  algorithm  allows  rules  to  have  patterns  marked  with  negative  signs.  A  rule 
containing  a  negative  pattern  can  only  run  if  none  of  the  data  in  the  database  match 
against  that  pattern.  These  patterns  are  usually  taken  to  represent  negation.  This 
technique  of  interpreting  an  absence  of  data  matching  a  pattern  as  a  “match”  for  the 
negation  of  the  pattern  is  known  as  the  closed  world  assumption  [22]. 

In  logical  deduction,  the  only  result  of  applying  an  inference  rule  is  to  deduce  a 
new  statement.  In  formalization  of  commonsense  reasoning  and  the  engineering  of  rule 
systems,  it  has  been  found  useful  to  also  allow  rules  to  retract  deductions,  and  to  remove 
terms  from  the  database.  The  0PS5  system  provides  this  facility.  When  a  term  is 
removed  from  the  database,  the  Rete  network  removes  all  entries  from  the  conflict  set 
that  involved  matching  against  that  term.  This  facility  is  not  present  in  the  matcher 
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derived  in  this  thesis.  It  could  be  added  to  the  matcher,  within  the  framework  developed 
here. 

In  most  rule  systems,  there  are  likely  to  be  a  number  of  patterns  that  appear  in 
several  rules.  It  is  inefficient  to  repeat,  for  each  rule,  the  computations  of  the  matches 
to  these  patterns.  A  better  scheme  is  to  share  results  of  matching  a  pattern  among  all 
of  the  rules  that  include  that  pattern.  The  Rete  network  performs  this  sharing. 

In  this  thesis  I  focus  on  deriving  the  central  architecture  and  features  of  the  Rete 
matcher:  the  division  of  the  matching  work  among  a  network  of  nodes,  and  the  incre¬ 
mental  update  of  the  conflict  set  as  changes  are  made  to  the  database.  For  consideration 
and  illustration  of  these  features,  it  suffices  to  analyze  the  matching  network  for  a  single 
rule  (that  itself  contains  several  patterns).  This  network  can  easily  be  extended  to  a 
Rete  network  for  a  set  of  rules.  Chapter  6  discusses  future  directions  for  extending  the 
derivation  to  include  these  features. 


Chapter  3 


Specification  and  Derivation 


This  chapter  presents  a  derivation  of  an  implementation  for  the  rule  matcher.  Section  1 
formalizes  the  abstract  specification 

match-rule(r,  d6)  =  Rep[{cr  |  Vpg  ih,(r)  3d&db  p"  =  <^}] 

presented  in  Chapter  2.  In  Section  2  the  conjunction  and  disjunction  in  this  specifica¬ 
tion  are  expressed  as  operations  on  infinite  sets  of  substitutions.  In  Section  3  a  natural 
ordering  on  substitutions  is  used  to  implement  these  infinite  sets.  In  Section  4  this  imple¬ 
mentation  is  generalized  to  properly  handle  disjunctions  of  substitututions.  This  chapter 
concludes  with  an  initial  implementation  for  the  rule  matcher.  Chapter  4  deals  with 
optimizing  this  implementation,  and  showing  its  correspondence  to  the  Rete  matcher. 

The  derivation  in  this  chapter  involves  the  construction  of  lattices  and  semilattices. 
The  reader  may  wish  to  review  Appendix  A.l  which  briefly  summarizes  some  standard 
algebraic  definitions. 


3.1  Formal  Specification 

In  this  section  we  develop  a  formal  specification  for  the  rule  system  pattern  matcher. 

For  our  mathematical  model  of  a  rule  system,  we  consider  the  objects  in  the  database 
to  be  terms  in  a  first-order  language,  and  the  rules  in  the  rulebase  to  be  inference  rules 
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in  a  first-order  language.^ 

First  we  need  a  formal  model  for  the  objects  in  the  database.  Let  V,  the  set  of 
variables,  and  C,  the  set  of  constants,  be  two  disjoint  sets.  Let  T,  the  set  of  terms,  be 
the  free  semigroup  generated  by  V  U  C.  (If  the  operation  for  this  semigroup  is  thought 
of  as  the  cons  function,  T  can  be  thought  of  as  the  set  of  s-expressions  that  can  be 
constructed  from  the  atoms  in  V  U  C.)  Let  G,  the  set  of  ground  terms,  be  the  set  of  all 
elements  in  T  that  do  not  contain  any  variables.  Using  these  definitions,  the  database  in 
a  rule  system,  is  represented  as  a  subset  of  G. 

Next  we  need  a  formal  model  for  the  rules  in  the  rulebase,  and  for  the  process  of 
applying  rules  to  data.  A  rule  contains  two  components;  a  Left  Hand  Side  (LHS),  and  a 
Right  Hand  Side  (RHS).  The  LHS  contains  a  set  of  terms  that  can  be  matched  against 
data  in  the  database.^  The  RHS  contains  a  term  that  can  be  instantiated  and  added  to 
the  database.  The  set  of  rules,  R,  is  therefore  the  set  2^  x  T,  and  the  rulebase  in  a  rule 
system,  r6,  is  a  subset  of  R. 

A  substitution  is  a  partial  function  from  V  to  G.^  Let  E  denote  the  set  of  all  substi¬ 
tutions.  VVe  will  use  the  Greek  letters  cr,  t  and  v  to  denote  substitutions. 

A  term  p  can  be  Instantiated  with  a  substitution  cr  by  replacing  all  of  the  variables 
in  p  with  their  images  in  cr.  If  any  of  the  variables  in  p  are  not  in  the  domain  of  cr.  the 
result  is  undefined.  We  use  the  notation  p'^  to  denote  this  instantiation,  and  refer  to  the 
term  p  as  a  pattern.  The  inverse  of  instantiation  is  matching.  The  result  of  matching 
a  pattern  p  and  a  datum  d  is  a  substitution  cr  such  that  p^  =  d.  A  full  description  of 
instantiation  and  matching  is  given  in  Section  6.2. 

The  matching  computation  performed  by  match-rule  is  the  central  part  of  the  rule 

Hn  Chapter  5  we  present  a  concrete  implementation  in  terms  of  Lisp  data  types. 

^In  many  rule  systems  implemented  and  used  in  real-world  applications,  the  order  of  the  patterns  in 
the  LIIS’s  of  the  rules  have  been  carefully  hand-tuned  by  the  programmers,  in  an  attempt  to  improve 
the  performance  of  the  system  [29].  To  accurately  model  these  systems  we  would  need  to  represent  the 
LHS  of  a  rule  as  a  sequence.  We  choose  to  retain  the  semantics  of  logic,  where  the  elements  in  a  conjunct 
are  unordered. 

^If  /  is  a  function,  we  will  use  the  notation  /(x)  to  denote  the  value  of  the  function  /  at  x.  and 
dom(/)  to  denote  the  domain  of  /. 
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system.  The  rest  of  this  chapter  concentrates  on  implementing  this  specification.  Chap¬ 
ter  4  focuses  on  incrementally  updating  the  value  of  match-rule  as  changes  are  made  to 
the  database. 


3.2  The  Representation  Problem 

This  section  motivates  the  representation  design  carried  out  in  Sections  3.3  and  3.4.  In 
order  to  synthesize  code  for  the  specification 

match-rule(r,  d6)  =  Rep[{cr  |  Vpg  ihB(r)  3dedb  =  d}],  (3.1) 

we  first  put  this  expression  into  a  form  where  it  can  be  decomposed  into  several  subparts. 
This  can  be  accomplished  by  rephrasing  the  specification  in  terms  of  operations  on  sets, 
i.e."* 

match-rule(r,  dh)  =  Rep[  [J  {cr  \  =  d]].  (3.3) 

p€  Ihs(r)  d£db 

This  expression  can  be  progressively  constructed  from  the  following  subexpressions: 

match(p,  d)  =  Rep[{(T  \  =  d}]  (3.4) 

match-elt-set(p,d6)  —  Rep[  [J  {<t  \p'*  —  d}]  (3.5) 

d^db 

match- rule( r,  d6)  =  Rep[  P)  [J  W  ]  p'^  =  d}].  (3.6) 

p€  lhs(>’)  d£db 

To  aid  in  understanding  this  specification  and  its  decomposition,  let  us  analyze  a 
small  example.  Consider  matching  a  rule  r,  with  a  LHS  given  by 

Ihs(r)  =  {pi,P2}  =  {(/  ?x),(p  ?y)}, 

“•The  correspondence  might  be  easier  to  see  if  we  write  the  quantifiers  as  logical  conjunction  and 
disjunction,  i.e. 

match-rule(r,  d6)  =  Rep[{<r  j  \/  p'' =  d}].  (3.2) 

p€  hu('')  d^di 
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against  the  database  given  by 

db  =  {di,  d2,  da,  d,}  =  {(/  1),  (/  2),  (g  3),  {g  4)}. 

A  diagram  of  the  values  of  the  subexpressions  in  Equations  3.4  to  3.6  is  shown  in  Figure  3- 

1. 

This  figure  demonstrates  the  key  idea  in  the  thesis:  the  explicit  representations  of 
sets  of  substitutions  for  the  conjunctive  match  problem  that  arises  from  matching  all  of 
the  patterns  in  a  rule,  and  for  the  disjunctive  match  problem  that  arises  from  matching 
a  pattern  against  all  of  the  terms  in  a  database. 

It  is  important  to  note  that  the  sets  of  substitutions  in  Equations  3. 1-3.6  and  Figure  3- 
1  are  infinite  sets.  For  example,  if  a  substitution  a  is  in  one  of  these  sets,  than  any 
extension  of  a  (i.e.  any  substitution  r  such  that  Vj,  ia-{x)  =  t{x)  V  cr(x)  =  lj) 
is  also  in  that  set.  If  =  {  i  h->.  1  }  is  in  one  of  these  sets  of  substitutions,  then 
r  =  {  z  1,  y  t— ►  2  }  is  also  in  the  set.  The  unboundedness  of  these  sets  is  necessary  in 

order  for  the  set  representing  a  conjunctive  match  of  two  patterns  p  and  q  to  be  equal  to 
the  intersection  of  the  sets  representing  the  matches  to  p  and  q. 

These  infinite  sets  of  substitutions  cannot  be  directly  stored  in  an  implementation. 
What  is  needed  to  implement  this  scheme  is  a  finite  representation  that  captures  the 
information  in  these  sets.  The  next  two  sections  present  the  derivation  of  such  a  repre¬ 
sentation. 


3.3  Representation  using  Maximal  Elements 

We  might  implement  the  infinite  set  of  substitutions  given  by 
5  =  {<T  I  zf  =  yi  A  Zj  =  yj  A  . . .  A  Zfc  =  yfc} 
by  the  single  substitution 

*The  symbol  ui  is  used  for  undefined,  since  the  symbol  ±  is  used  for  the  bottom  element  in  the  lattice 
introduced  in  Section  3.3. 
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Ihs(r)  =  {pi,P2}  =  {(/  '^■x),{g  ?y)} 

db  =  {dud2.  d„  d,}  =  {(/  1),  (/  2),  (g  3),  (g  4)} 

Abs[match(pi,<ii)]  =  {<7  I  pf  =  =  W  \  if  =  (/  1)}  =  =  1}  =  ,4 

Abs[match(pi,<f2)l  =  {<?■  1  Pt  =  ^2}  =  {<^  1  (/  =  if  2)}  =  W  =  2]  =  B 


Abs[match(p2,<f3)]  =  {<?■  I  Pj  =  <^3}  =  {(^  I  (P  ?y)'  =  (p  3)}  =  {cr  |?y'  =  3}  =  C 
Abs[match(p2,<f4)l  =  {<?■  I  P2  =  <^4}  =  {<7  1  (P  '^vY  =  (p  =  W  l-P'^  =  4}  =  £? 

cn]  Abs[match-elt-set(pi,<i6)]  =  [J  {a  |  pf  =  d}  =  A  U  B 


d&db 


Abs[match-elt-set(p2,<^6)]  =  U  |  pj  =  <i}  =  C  U  D 


d^db 


Abs[match-rule(r, (f6)]  =  P|  [J  {(7  |  =  cf}  =  ( A  U  5)  fi  (C  U  D) 

pG  llis(r)  d^db 


Note.  Abs[match(pi.(i3)]  =  Abs[match(p,.(i4)l  =  Abs[match(p2.<ii)l  =  Abs[match(pj.<ij)l=a. 


Figure  3-1:  Venn  diagram  illustrating  Conjunctive  Pattern  Matching. 
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/?ep[5]  =  {xi  yi,i2  j/fc}. 

That  is,  represent  the  set  of  all  mappings  that  take  Xi  to  yi,  and  I2  to  r/2>  etc.,  by  the 
mapping  that  takes  ii  to  yi,  and  X2  to  y2,  etc. 

To  formalize  this  representation,  we  can  order  the  set  E  using  the  ordering® 


(T  ^  Vugv  =  x’’  V  x’’  =  u;) 


(3.7) 


and  then  represent  a  set  by  its  maximal  element  under  this  ordering. 

In  this  ordering,  a  substititution  <t  is  -<  a  substitution  r  iff  it  agrees  with  r  on  all  of 
the  variables  on  which  r  is  defined,  and  is  defined  on  some  additional  variables. 

The  structure  consisting  of  the  set  of  substitutions  E  with  the  ordering  given  in 
Equation  3.7  forms  a  semi- lattice.  See  Figure  3-2.  To  complete  this  semi-lattice,  we  can 
introduce  a  bottom  element  ±,  such  that  ±  ^  <t.  We  will  refer  to  this  semi-lattice 
as  the  Substitution  Semi-Lattice  (SSL).^ 


®Note  that  this  derivation  will  involve  two  different  lattices.  The  ordering  in  this  first  lattice,  SSL, 
will  be  denoted  by  rr  ^  r.  The  ordering  in  the  second  lattice,  DSL  (introduced  in  the  ne.Kt  section),  will 
be  denoted  by  T  C  . 

^The  ordering  defined  for  SSL  in  Equation  3.7  is  based  on  the  considering  the  substitutions  as  map¬ 
ping.  Alternatively,  this  ordering  could  be  expressed  in  terms  of  the  operation  of  the  substitutions  in 
instantiating  patterns.  The  alternative  expression  is 

er  <  T  'ip  'i i  =  d  p”  =.  d).  (3.8) 
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Figure  3-3:  A  Principal  Ideal  in  the  Substitution  Semi-Lattice. 


The  greatest  lower  bound  of  two  elements  in  this  semi-lattice  is  given  by  * 

{Ax. (if  x"  =  u)  then  i’’  else  x*^)  if  <t  =  t 

^  (3.9) 

J.  otherwise. 

To  be  precise  about  the  representation  and  the  object  being  represented,  we  can  define 
the  following  representation  and  abstraction  functions^ 

Rep[5  C  E]  =  <r  I  <r  X  T 
Abs[r  &  E]  =  {<t\(T 

A  portion  of  SSL,  with  a  set  of  substitutions  marked,  is  shown  in  Figure  3-3.  In  this 
diagram  we  can  see  that  Abs(<r)  is  the  “cone”  of  elements  below  <t  in  the  semi-lattice. 
That  is,  Ab8(<r)  is  the  principal  ideal  in  SSL  generated  by  a. 

In  this  representation,  the  resuH  of  matching  a  single  pattern  and  datum  can  be 
represented  by 

match(p,<2)  =  Rep[{<T  [  =  d}].  (3.10) 

This  allows  us  to  implement  the  specification  of  Equation  3.4  which  denotes  the  result 
of  matching  a  pattern  and  a  datum.  In  order  to  use  this  representation  to  implement  the 

*The  symbol  =  denotes  weak  equality,  i.e.  ^  =  r  «-*  V,  (<t(z)  =  t{x)  V  <r(j6)  =  w  V  t(*)  =  w). 

*Fot  a  description  of  the  use  of  abstraction  functions,  see  [16]. 
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match-rule  specification,  we  must  also  be  able  to  represent  the  unions  and  intersections 
of  sets  of  substitutions,  as  specified  in  Equations  3.5  and  3.6. 

We  can  represent  intersection  of  substitution  sets,  as  required  by  Equation  3.6,  by 
the  greatest  lower  bound  operation  in  the  lattice:^® 


Rep[Abs[a\  f)  y46s[r]] 


Rep[{v  I  u  n  {u  I  u  r}] 
Rep[{v  I  u  ^  <T  A  u  :::<  r}] 
Rep[{v  !  u  ^  cr  n"  t}] 
Rep[Abs[a  FI*  r]] 
crn*  r. 


This  is  illustrated  in  Figure  3-4  by  the  intersection  of  the  two  ideals  generated  by  the 
elements  {x  ►  1}  and  {y  3}. 

The  fact  that  the  greatest  lower  bound  in  the  lattice  corresponds  to  intersection  of 
the  sets  of  substitutions  can  be  stated  algebraically  as:  the  representation  function  is  a 
(lattice)  homomorphism  from  (2^,  C,n)  to  {E,  (Since,  as  stated  in  .Appendi.x 

.4.2,  any  powerset  forms  a  lattice  under  the  subset  relation.) 

^°assuming  that  these  sets  are  principal  ideals  generated  by  some  element.  This  limitation  is  removed 
in  the  representation  introduced  in  Section  3.4. 

“again,  restricting  the  elements  in  2^  to  principal  ideals. 
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Unfortunately,  this  representation  cannot  represent  unions  of  sets  of  substitutions  as 
required  by  Equation  3.5.  For  example,  the  set  of  substitutions  that  represents  all  of 
the  matches  between  the  pattern  (/  ?z)  and  the  database  {(/  1),  (/  2)},  is  given  by 
{<7  I  x*'  =  1  V  x*'  =  2}.  This  set  does  not  have  a  greatest  element,  amd  therefore 
it  does  not  have  a  representation  in  the  above  semi-lattice.  Stated  algebraically,  this 
structure  is  a  semi-l&ttice,  and  not  a  lattice,  because  there  is  no  operation  U*  such  that 
the  Representaton  function  is  a  homomorphism  from  (2®,C,U)  to  (i;,^,U*). 


3.4  Representation  using  Sets  of  Maximal  Elements 

This  problem  can  be  remedied  by  changing  the  representation.  Instead  of  representing 
a  set  of  substitutions  S  by  a  single  maximal  element,  we  can  represent  it  by  a  set  of 
maximal  elements  ^cp[5],  so  that  for  every  element  a  in  5,  there  is  some  element  r  in 
iiep[5],  such  that  a  We  will  use  the  capital  Greek  letters  T,  $,  $  and  F  to  denote 
sets  of  maximal  elements  in  E. 

These  sets  of  msodmal  elements  can  be  ordered  by  the  following  extension  to  the 
ordering  used  in  Section  3.3.  Let  a  set  of  substitutions  T  be  less  than  (C)  a  set  of 
substitutions  $,  iff  every  substitution  in  T  is  less  than  {:<)  some  substitution  in  $,  i.e. 

T  C  $  ♦-+  3r6#  <r  :<r.  (3.11) 

The  result  of  this  set  and  ordering  is  a  new  lattice  (see  Figure  3-5),  which  will  be  referred 
to  as  the  Disjunctive  Substitution  Lattice  (DSL).^^ 

Unlike  the  semi-lattice  described  in  Section  3.3,  DSL  is  a  lattice,  with  both  a  greatest 

^’The  ordering  given  in  Equation  3.11  can  also  be  expressed,  as  we  did  for  ^  in  the  previous  section, 
in  terms  of  the  operation  of  the  substitutions  in  instantiating  patterns.  This  alternative  definition  is 
given  by 

T  C  *  ^  V,  [(3,€T  p'  =  d)  -  P"  =  d)].  (3.12) 
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lower  bound  and  a  least  upper  bound.  These  operations  are  given  by*^ 


(3.13) 

(3.14) 


Tj$  =  TU$ 

Tn$  =  {o  I  Brer  o"  =  7"  n*  u}. 

For  this  representation,  the  representation  and  abstraction  functions  are  given  by 
Rep[5C£;]  =  \~\S 

^^Equation  3.13  is  a  slight  oversimplification.  In  cases  where 
3ff6T  3r€*[(<T  -<  r)  V  (r  -<  <r)], 

the  value  of  T  U  $  can  be  simplified  using  identities.  For  example, 

These  cases  do  not  arise  in  any  of  the  programs  in  this  thesis,  since  we  only  apply  U  to  sets  of  disjunctive 
substitutions  that  represent  alternative  matches  for  the  same  pattern.  Consequently,  these  disjunctive 
substitutions  have  the  same  domains,  and  their  least  upper  bounds  cannot  be  reduced  using  identitities. 
In  these  cases.  Equation  3.13  holds. 
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Abs[T]  =  {cr  I  3reT  cr  ■<  r}. 

Note  that  whereas  elements  in  SSL  could  only  represent  principal  ideals  of  elements 
in  SSL  (i.e.  “cones”  of  elements  in  the  diagrams),  any  ideal  of  elements  in  SSL  can 
be  represented  by  an  element  in  DSL  (even  those  that  are  represented  by  sets  of  cones 
in  the  diagram).  It  can  therefore  be  shown  that  all  unions  and  intersections  of  sets  of 
substitutions  can  be  represented  in  DSL,  as  required  by  the  specifications  in  Equations  3.5 
and  3.6.  These  values  are  given  by 

Rep[51  U  S2]  =  Rep[5l]  U  Rep[52]  (3.15) 

and  Rep[5l  n  52]  =  Rep[5l]  n  Rep[52].  (3.16) 

The  specification  for  match-rule  in  Equation  3.3  can  now  be  implemented  by  using 
representations  in  DSL.  This  implementation  is  given  by 

match-rule(r,  db)  =  n  u{'^  I  ?'=''}•  (317) 

p€  lh8(r)  d^db 

Note  that  this  implementation  is  isomorphic  to  the  specifications  shown  in  Equations  3.1 
and  3.3.  That  is,  the  specification  in  Equation  3.3  and  the  implementation  in  Equa¬ 
tion  3.17  represent  equivalent  expressions  in  two  homomorphic  lattices:  the  set  algebra 
of  the  specification,  and  the  Disjunctive  Substitution  Lattice  (DSL)  of  the  implementa¬ 
tion. 

Finally,  we  can  finish  the  implementation  by  replacing  the  expression  for  the  result 
of  matching  a  single  pattern  and  datum  with  the  match  function.  To  be  consistent  with 
the  format  of  the  elements  in  DSL,  the  specification  for  match  given  in  Equation  3.10 
can  be  slightly  modified  so  that  it  returns  a  (singleton)  set  of  substitutions,  i.e. 

match(p,  d)  =  {cr  |  =  d}}.  (3.18) 

Substituting  this  equation  into  equation  3.17  and  simplifying  yields 

match-rule(r,  d6)  =  f~|  [J  (c’’ 1  =  d) 

p€  lhs{r)  d^db 
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(3.19) 


=  n  U  n*{(7 !  p*"  =  c/} 

p€  Ihs(r)  d^db 

=  n  u  match(p,  d). 

p€  Ihs(r)  d&db 

Equation  3.19  is  the  final  form  of  our  initial  implementation  of  match- rule.  Note 
that  this  equation  constitutes  an  executable  program.  For  example,  in  Lisp  this  equation 
could  be  implemented  as 


(defun  match-rule  (r  db) 
(reduce 

(mapcar  (lambda  (p) 


(Ihs  r)))) 


(reduce  #’1J 

(mapcar  (lambda  (d) 
db))) 


(match  p  d)) 


with  n  and  U  as  defined  above.  (Note  that  the  definitions  presented  above  for  H,  U,  and 
U*  also  constitute  executable  programs,  as  shown  in  Figures  5-4  and  5-5.) 

The  next  chapter  starts  with  this  program,  optimizes  it,  and  show  its  correspondence 
to  the  Rete  algorithm.  Chapter  5  presents  an  implementation,  using  program  transfor¬ 
mations,  of  this  derivation,  and  of  the  optimizations  presented  in  Chapter  4. 
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Chapter  4 


I 


Correspondence  to  Rete  and 
Optimization 


This  chapter  demonstrates  the  correspondence  between  the  matcher  developed  in  Chapter 
3  and  the  Rete  network,  and  optimizes  this  matcher  using  finite  differencing  and  partial 
evaluatioi. 


4.1  Correspondence  to  the  Rete  Matcher 

In  the  last  chapter  we  derived  the  following  program  for  match-rule  (Equation  3.19): 
match-rule(r,  db)  =  n  u  match(p,  d) 

p^lha^r)  d^db 

We  can  now  show  the  correspondence  between  this  formulation  of  match-rule,  and 
a  Rete  network  (for  a  single  rule).  Let  us  consider  a  decomposition  of  this  program 
analogous  to  the  decomposition  of  the  specification  in  Equations  3.4  to  3.6.  .Assume 
that  a  rule  r  has  k  patterns,  and  label  them  pi,p2, . . .  ,Pk-  If  we  define  a  vector  R 
(corresponding  to  the  right  memories  of  the  nodes  in  a  Rete  network)  as 

U  match(p,',d)  for  1  <  i  <  (4.1) 

d^db 

then  this  expression  for  match-rule  in  can  be  written  as 
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1  function  match-rule(r,  c/6) 

2  let  k  =  length(lhs(r)) 

3  for  i  =  I,  k 

4  Ri  ^  Uiedi  match((lhs(r))i,  d) 

5  £i  <—  if  z  =  1  then  Ri 

6  else  Li^i  n  Ri  end  if 

7  end  for 

8  return  Lk 

9  end  function 


Figure  4-1:  Match-Rule  Implementation. 

match-rule(r,  db)  =  /?i  PI  i?2  H  i?3  fl . . .  D  (4.2) 

Since  n  is  associative,  this  expression  can  be  parenthesized  as 

match-rule(r,  db)  =  (. . .  {{Ri  H  R2)  PI  R^) . . .)  PI  Rk.  (4.3) 

If  we  label  these  parenthesized  expressions  as  elements  of  a  vector  L  (corresponding 
to  the  left  memories  of  nodes  in  a  Rete  network),  i.e. 

Li  —  Ri  (4.4) 

and  Li  =  Zr,_i  PI  R,  for  2  <  i  < 

then  the  expression  for  match  rule  can  be  written  as 

match-rule(d6,  r)  =  Lk-  (4.5) 

The  formulation  in  Equations  4.1,  4.4  and  4.5  is  collected  in  Figure  4-1  into  an  imple¬ 
mentation  of  match-rule. 

The  correspondence  between  the  implementation  of  match-rule  in  Figure  4-1,  and 
the  Rete  network  described  in  Chapter  2,  is  illustrated  in  Figure  4-2.  We  can  see  the 
correspondence  by  identifying  the  Li  and  Ri  values  in  match-rule  with  the  contents  of 
the  Left  and  Right  input  memories  of  the  combine  nodes  in  the  Rete  network. 
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Changes  to  Database 


match  node 


combine  node 


memory 


Figure  4-2:  Correspondence  between  Match-Rule  and  the  Rete  Network. 
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Note  that  this  correspondence  holds  for  the  topology  of  the  network,  but  not  for  its 
behavior  over  time.  Whereas  match-rule  is  a  functional  program^  the  Rete  network  in¬ 
crementally  updates  the  contents  of  the  node  memories.  The  correspondence  between  the 
derived  program  and  the  Rete  network  will  be  extended  to  include  the  incremental  be¬ 
havior  in  the  next  section,  and  the  remaining  differences  will  be  discussed  in  Sections  5.4 
and  6.2. 


4.2  Optimization 

The  major  source  of  efficiency  in  the  Rete  matcher  is  its  incremental  update  of  the  conflict 
set  as  the  database  is  modified.  This  section  will  present  a  derivation  of  this  optimization, 
and  apply  it  to  the  program  under  development. 

Let  us  assume  that  the  database  is  large,  and  therefore  changes  relatively  slowly,  since 
only  one  element  is  added  to  it  on  each  cycle.  Let  us  further  cissume  that  the  computation 
of  match-rule  is  expensive.  This  situation  suggests  that  the  performance  of  the  system 
could  be  improved  by  finite  differencing  [19]  the  computation  of  match-rule  with  respect 
to  the  updates  to  the  database. 

This  finite-differencing  can  be  carried  out  as  follows.  Consider  the  operation  of  the 
rule  system  interpreter  over  two  cycles.  Let  db  be  the  input  data  to  the  first  cycle;  let  R, 
and  Z,  be  the  values  computed  during  this  first  cycle;  let  db  be  the  new  data  generated 
during  this  cycle,  and  let 

db  =  dbu  db 

be  the  resulting  database  carried  over  to  the  next  cycle  of  the  interpreter.  Let  the  values 
of  R,  and  Z,  be  the  values  computed  during  the  second  cycle,  and  let  R,  and  Z,  be  the 
changes  to  R  and  Z  from  the  first  cycle  to  the  second,  i.e. 

7^  =  /?,  U  R, 

^The  program  in  Figure  4-1  is  a  single-assignment  program. 
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Li  =  Li  U  Li. 

Now,  using  the  associative  law^  for  U 

LI  {<^  \  p'"  =  d)  =  \_\  {a  \  =  d]  (4.6) 

d^dblUdb2  dedbl 

U  i\  {<7  \p’^d} 

d&db2 

and  the  distributive  law^  for  □  over  U 

(Tu$)n(^ur)  (4.7) 

=  (Tn'ir)u(Tnr)u(<5n^)u($nr) 

we  can  derive  that 


^  =  U  I  P""  =  4 

d^dbijdh 

=  U  {'^  I  P'  =  U  U  {<7  I  p"  =  <i} 

dedb 

=  RiU  Ll{<^lp'  =  <i} 

d€<ib 


(4.S) 


(4.9) 


and  (for  i  >  2) 


^Let  .4=  {ai . a„}  and  B  =  {bi,...,bm}-  Then 

□  fix)  =  /(ai)U...U/(a„)U/(6i)U...U/(6,„) 

i^AuB 

=  (/(ai)  U  . . .  U  /(a„))  U  (/(6i)  U  . . .  U  f{b,n)) 

=  (  □  /(I))  U  ( iJ /(x)). 


^Since  T  U  <5  =  T  U  therefore 

(Tu$)n'I'  =  {cr  I  3rgxu<s  a  =  r  n*  u} 

=  {<’■  I  3rgTo*  3ug*  <7  =  r  n*  y} 

■”  I  3TgT  3vg'j'  ^  —  7  n  u)  U  j  3^^^  ^  *  7  n  L') 

=  W  I  3r6T  3vg#  (T  =  7  n*  u}  u  {a  I  3pg*  3vg>J  (T  =  7  n‘  L>} 

=  (Tn$)u($n't). 
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Li  —  Li—X  n  Hi 

=  (L._x  uLiLi)n(i?.  u^.)  (4.10) 

=  (L._i  n  Ri)  u  (L-_i  n  Ri)  u  (l._i  n  Ri)  u  {L-.i  n  i?.) 

=  L.- u  n /i.)  u  (I._i  n  i?,)  u  (L,'_i  n  i?,).  (4.ii) 

If  we  assume  that 

1  db  1>1  db  1, 

then  the  computations  in  Equations  4.9  and  4.11  are  less  expensive  than  the  computations 
in  Equations  4.8  and  4.10,  since  the  sets  being  manipulated  are  much  smaller. 

Figure  4-3  incorporates  the  match-rule  code  from  Figure  4-1  into  the  original  inter¬ 
preter  of  Figure  2-1,  and  Figure  4-4  transforms  this  interpreter,  using  the  optimizations 
presented  in  this  section,  into  an  incremental  interpreter. 

Lines  3-6  in  Figure  4-4  perform  the  initial  computation  of  the  L  and  R  values.  Line 
S  generates  the  conflict-set  from  Lk-  Lines  10-12  select  a  rule  and  substitution  from 
the  conflict  set,  instantiate  the  rule  with  the  substitution  to  obtain  a  new  datum,  and 
add  the  new  datum  to  the  conflict  set.  Line  14  computes  the  update  to  the  R  values 
resulting  from  the  addition  of  the  new  data,  and  lines  15-16  compute  the  updates  to  the 
L  values  that  result  from  the  updates  to  the  R  values.  Lines  18-20  add  the  new  elements 
computed  in  lines  14-16  to  the  L  and  R  values. 

Figure  4-5  presents  the  rule  interpreter  after  partial  evaluation.  The  partial  evalua¬ 
tion  consists  of  unrolling  the  loops  in  Figure  4-4  into  the  single  assignment  statements 
in  Figure  4-5.  Each  of  the  expressions  in  Figure  4-5  represents  (according  to  the  corre¬ 
spondence  shown  in  Figure  4-2)  a  value  computed  by  a  node  in  the  Rete  network,  and 
the  variable  references  and  assignments  represent  the  dataflow  between  the  nodes. 

This  concludes  the  formal  algorithm  derivation.  The  next  chapter  will  present  an 
implementation  of  this  derivation  using  a  program  transformation  system. 
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1  function  single-rule-system  (r,  db) 

2  let  k  =  size(lhs(r)) 

3  repeat 

4  for  i  =  I,  k 

5  Ri  Udedb  match((lhs(r))„  d) 

6  <—  if  t  =  1  then  Ri 

7  else  Z/,_i  n  Ri  end  if 

8  end  for 

9  C3  ^  \(T  e  Lk} 

xo  if  cs  =  0  then  return  dh  end  if 

11  *—  conflict-resolution(cs) 

12  dh  ♦—  {rhs(r)‘^} 

13  db  *—  dh\J  dh 

14  end  repeat 

15  end  function 

Figure  4-3:  Rule  Syste^  for  a  Single  Rule. 
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function  single-rule-system  (r,  dh) 
let  k  =  si2e(lhs(r)) 
for  i  =  \,k 

Ri  U<f€<i6inatch((lhs(r)).-,<i) 

Z,i  4—  if  i  =  1  then  Ri 

else  Li-i  n  Ri  end  if 

end  for 

cs  *-  {{r,a)  \<T  e  Lk} 
while  cs  ^  0 


10 

(r,  <t)  ♦—  conflict-resolution(i 

11 

db  4—  {rhs(r)‘^} 

12 

db  dbU  db 

13 

for  t  =  1,  A: 

14 

Ri  ^  Ud^db  niatch(p,-,  d) 

15 

Z,  4—  if  i  =  1  then  Ri 

16 

else  {Li-i 

17 

end  for 

18 

for  i  =  l,k 

19 

Ri*-  RiU  Ri 

20 

Li  4-  Li  u  Zi 

21 

end  for 

22 

end  while 

23 

return  db 

else  (Li-i  n  Ri)  U  (Z-j_i  n  Ri)  U  (X,_i  PI  i?,)end  if 


24  end  function 


Figure  4-4:  Incremental  Rule  System. 


1  function  single- rule- system  (r,<f6) 
3  let  lli8(r)  =  (pi,pj,p3) 


3  Ri  Uig*match(pi,<<£) 

4  Ri*-  Udg jfc  match(p2 ,  d) 

6  Rz  <—  match(p3,  d) 


6  Li  < —  Ri 

7  Xj  < —  Li  n  Rj 

8  is  < —  is  n  iZs 

9  repeat 

10  C8  ♦—  {(r,  <r)  I  <T  €  is} 

11  (»’»<^)  conflict- resolution(cj) 

12  46  *-  rlis(r)‘^} 

13  dh  < —  dh  U  dh 


M  ^1  Udedh  match(|h,  d) 

18  Ri  *-  LUeA  niatch(j)3,  d) 

18  Ri  *-  Uigi  match(p3,  d) 

17  L\  < —  Ri 

is  i,  -  (iinie3)u(iin/ij)u(iin/E,) 

19  Li  *—  {Li  n  Ri)  U  {Li  n  Ri)  U  {Li  fl  Ri) 


30 

31 
33 

33 

34 

35 

36 

37 

38 


Ri  *—  RiU  Ri 
Ri  *—  Ri  U  Ri 
Ri  ♦—  Ri  U  Ri 
ij  «—  ii  U  ii 
ij  <—  is  U  Li 

Li  *—  LiU  Li 
until  cs  =  0 
return  dh 
end  function 


Figure  4-5:  Rule  System  after  Partial  Evaluation. 
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Chapter  5 


Implementation  using 
Transformations 


This  chapter  describes  an  implementation,  using  a  program  transformation  system,  of 
the  derivations  described  in  Chapters  3  and  4.  A  first  set  of  transformations  is  used 
to  transform  the  specification  into  an  initial  implementation  by  transforming  the  uni¬ 
versal  and  existential  quantifiers  in  the  specification,  first  into  set  operations,  and  then 
into  lattice  operations.  A  second  set  of  transformations  is  used  to  optimize  the  initial 
implementation  by  performing  finite  differencing  and  partial  evaluation. 

Sections  5.1  and  5.2  introduce  transformation  systems  in  general,  and  specifically 
the  Refine  language  used  in  this  implementation.  The  next  three  sections  describe  the 
implementation.  Section  5.3  presents  the  preliminaries  for  the  development.  These  in¬ 
clude  the  types  used  in  system,  some  sample  data  and  rules,  the  match  and  instantiate 
functions,  and  the  lattice  operations.  Section  5.4  presents  the  rule  system  specifications, 
the  transformations  used  in  the  initial  implementation,  and  the  resulting  code.  Section 
5.5  presents  the  transformations  used  for  finite  differencing  and  partial  evaluation,  and 
presents  the  resulting  optimized  code.  Section  5.6  describes  the  current  status  of  the 
implementation,  and  describes  further  work  to  be  done,  such  as  automatically  synthe¬ 
sizing  the  match,  instantiate,  and  lattice  operations,  and  automating  the  control  of  the 


transformation  applications. 


5.1  Transformation  Systems 

This  section  describes  transformation  systems  in  general,  and  the  Refine  language  in 
particular. 

A  transformational  development  begins  with  a  complete  formal  specification  for  the 
target  program.  Correctness-preserving  tranformations  are  then  applied  to  this  specifi¬ 
cation  to  derive  the  program.  These  transformations  embody  fragments  of  programming 
knowledge.  Specifically,  a  transformation  is  a  rewrite  rule  that  replaces  a  fragment  of 
source  text  with  an  equivalent  fragment  (that  hopefully  represents  a  step  towards  the 
final  implementation). 

Note  that  transformations  are  local,  i.e.  they  apply  to  a  local  piece  of  the  specification 
and  generate  a  local  piece  of  code.  The  paradigm  of  transformational  programming  relies 
on  the  specification  and  the  resulting  program  having  the  same  locality.  Some  attempts 
have  been  made  to  remove  this  restriction  by  having  transformation  systems  gather 
information  from  other  parts  of  the  specification,  e.g.  from  the  contexts  of  a  source 
expression  within  the  syntax  tree  [31]. 

Note  also  that  transformational  programing  can  be  either  semi-automatic,  where  the 
user  specifies  which  transformations  to  run  and  which  nodes  of  the  syntax  tree  to  run 
them  on,  or  fully  automatic,  where  the  system  makes  these  decisions.  The  implementation 
presented  in  this  chapter  is  semi-automatic.  The  final  section  of  this  chapter  discusses 
possibilities  for  completely  automating  the  derivation. 

A  transformation  system  requires  a  language  for  specifications  and  a  language  for 
implementations.  A  wide-spectrum  language  is  a  single  language  that  can  be  used  for 
expressing  both  specifications  and  implementations.  Its  constructs  range  from  high- 
level,  and  possibly  non-executable  constructs  such  as  unbounded  quantifers,  to  the  usual 
low-level  constructs  found  in  programming  languages. 
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Refine  [21]  is  a  strongly-typed  language,  containing  AlgoI-Iike  program  constructs, 
e.g.  if. .  .then. .  .else,  along  with  higher-level  mathematical  constructs,  e.g.  set-formers 
such  as  {i  I  (x)x  €  5  A  X  >  1}.  Refine  is  built  on  an  object  database.  All  objects  in  the 
system — types,  variables,  functions,  transformation  rules — are  stored  in  a  single  database. 

Refine  has  the  standard  primitive  data  types  such  as  numbers,  symbols,  etc.,  similar  to 
the  datatypes  in  Lisp.  Refine  allows  the  definition  of  compound  data  types.  The  following 
are  the  type  declarations,  syntax  for  literal  values,  and  syntax  for  general  expressions,  for 
the  data  types  used  in  this  derivation.  Note  that  both  the  set-former  and  the  map-former 
contain,  after  the  “|”,  a  list  of  variables  local  to  the  expression. 


datatype 

type  declaration 

literal  expression 

former  expression 

set 

map 

sequence 

tuple 

set(T) 

map(Tl,  T2) 

seq(T) 

tuple(fl:Tl,  f2:T2) 

{1,2,3} 

{11^3,2^51} 

[1.2.3] 

(1.2.3) 

{x  1  (x)  p(x)} 

{I  X  j/  1  (x,y)  p(x,y)  1} 

The  set  operations  that  we  will  use  are  union  (U),  intersection  (H),  adjoin  an  element 
to  a  set  {S  with  x),  construct  the  image  of  a  function  on  a  set  (image(/,  5)),  and  reduce  a 
set  using  a  binary  operation  (reduce(op,  5)).  For  maps  we  will  use  dom{m)  which  returns 
the  domain  of  the  map  m,  and  m(x)  which  returns  the  image  of  x  in  map  m. 

5.2  Types  and  Operations 

This  section  will  present  preliminaries  for  the  development,  including  type  declarations 
and  sample  data,  the  match  and  instantiate  functions,  and  the  lattice  operations.  In 
this  implementation  these  primitive  functions  have  been  written  manually.  Section  5.5 
describes  how  these  functions  might  be  automatically  synthesized. 

Figure  5-1  shows  the  declarations  of  the  types  used  in  the  system.^  Variables  and 

LVote  that  for  the  implementation,  the  prefix  character  for  variables  has  been  changed  from  “?”  to 
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constants  are  both  symbols,  and  they  are  differentiated  by  the  variablep  and  constantp 
predicates  shown.  Databeise  terms  are  s-expressions  containing  variables  and  constants. 
This  type  should  be  a  union  of  variables,  constants,  and,  recursively,  pairs  of  terms.  Since 
Refine  lacks  union  types,  an  escape  from  the  type  system,  any-type,  was  used.  Rules 
are  represented  as  tuples  of  the  LHS  and  RHS.  The  lattice  elements  are  represented  as 
described  in  Chapter  3.  A  substitution  (SUBST)  is  a  map  from  variables  to  terms,  and  a 
disjunctive  substitution  (DSUBST)  is  a  set  of  substitutions.  Finally,  the  figure  includes  a 
sample  database  and  rulebase. 


(def object  TERM*  type  ■  any-type) 

(def object  VARIABLE*  type  *  symbol) 

(defobject  CONSTANT*  type  *  symbol) 

(defobject  RULE*  type  ■  tupleClhs :set(term*) ,  rhsiterm*)) 

(defobject  SUBST*  type  *  map (variable*,  term*)) 

(defobject  DSUBST*  type  ■  aet(8ubst*)) 

(defobject  VARIABLEP*  function  (p:  term*) 

:  boolean  * 
if  8ymbolp(p) 

than  (symbol-to-string(p) ) (1)  »  #\- 
alse  false) 

(defobject  CONSTANTP*  function  (p:  term*) 

:  boolean  => 

if  symbolp(p)  then  -< variablep* (p)  else  false) 

(defobject  *DB*  var:  set  (term*)  »  -CC'f.'a],  C’f.’b],  [’f,  ’c],  C'g,  ’a], 

C’g.  ’b],  C>h,  'a,  'b], 

[’if,  'q,  ’r],  ’q}) 


(defobject  *RB*  var:set(rule*)  » 

’-x],  C’g,  ’-y],  C’h,  ’-X,  ’-y]}, 
C’p.  ’-X.  >-y]>. 

<{C’if,  ’-X,  '-y],  '-x}, 

’-y>}) 


Figure  5-1:  Implementation  Data  Types. 


This  was  necessary  because  the  Refine  grammar  does  not  allow  symbols  to  begin  with  Also, 
to  avoid  conflicting  with  predefined  types  in  Refine,  an  aisterisk  was  appended  to  the  names  of  all  types 
defined  in  this  derivation. 
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The  code  for  instantiate  and  for  match  is  shown  in  Figures  5-2  and  5-3. 


(daf object  INSTANTIATE  function  (p:  term*, 
:  term*  ■ 
if  constantp*(p) 
then  p 

else  if  variablep*(p) 

then  if  p  6  domain Cs) 
then  s(p) 
else  undefined 

else  cons(instantiate(car(p)  ,  s) , 


s:  subst*) 


instantiate (cdr(p) , 


s))) 


Figure  5-2:  Instantiate  Implementation. 


(defobject  MATCH  function  (p:  term*,  d:  term*) 

:  dsubst*  * 
if  constantp*(p) 
then  if  p=d 

than  {  -Cl  |}  > 
else  {} 

else  if  variablep*(p) 

then  {  fl  p  *-►  d  |}  } 
else  if  constantp*(d) 
then  {> 

else  dsubat-meet(match(car(p) ,  car(d)), 
match(cdr(p) ,  cdr(d)))) 


Figure  5-3:  Match  Implementation. 


Instantiate  takes  ais  arguments  a  term  and  a  substitution,  and  returns  the  term  that 
results  from  replacing  all  of  the  variables  in  the  term  with  their  images  in  the  substitution. 
It  is  implemented  using  structural  (“car-cdr”)  recursion  on  the  term.  Match  takes  as 
arguments  two  terms,  a  pattern  and  a  datum,  and  returns  a  disjunctive  substitution 
(DSUBST*)  under  which  the  two  are  equivalent.  Match  recurses  down  the  two  structures 
in  parallel.  If  a  variable  is  encountered  in  the  pattern,  it  creates  a  substitution  binding 
that  variable  to  the  corresponding  structure  in  the  datum.  If  the  corresponding  parts  of 
the  pattern  and  datum  differ  in  any  other  way,  it  returns  failure  (an  empty  DSUBST*). 
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The  code  for  the  lattice  operations  is  shown  in  Figures  5-4  and  5-5.  These  operations 
are  straightforward  translations  of  the  definitions  in.  Chapter  3. 


(def object  SUBST-MEET  function  (si:  subst*, 

s2:  subst*) 

:  subst*  a 

let  (dom  «  domain(sl)  U  domain(s2)) 

if  3(x)  (x  €  dom  A  dl  *  sKx)  A  d2  »  s2(x) 

A  defined? (dl)  A  defined? (d2) 

A  dl  7^  d2) 
then  undefined 
else 

{]  X  if  defined?(sl(x))  then  sl(x)  else  s2(x) 
1  (x)  X  €  dom  1>  ) 


Figure  5-4:  Substitution  Semi-Lattice  Meet. 


(defobject  DSUBST-MEET  function  (dsl:  dsubst*,  ds2:  dsubst*) 
:  dsubst*  » 

{  s  I  (si,  s2,  s)  si  e  dsl  A  s2  €  ds2 
A  s  =  subst“meet(sl,  a2) 

A  defined? (s)  >) 

(defobject  DSUBST- JOIN  function  (dsl:  dsubst*,  ds2:  dsubst*) 
:  dsubst*  ■ 
dsl  U  ds2) 


Figure  5-5:  Disjunctive  Substitution  Lattice  Operations. 


5.3  Initial  Derivation 


This  section  presents  the  rule  system  specifications.  The  specification  shown  in  Figure  5- 
6  is  a  straightforward  Refine  translation  of  the  specification  in  Figure  2-1.  Since  we  are 
only  concerned  with  the  matching  part  of  the  rule  system,  a  stub  has  been  inserted  for 
the  conflict-resolution  procedure.^ 

■A  stub  has  also  been  inserted  for  the  representation  operation  (R«p),  to  satisfy  the  requirement  of 
the  Refine/KIDS  system  that  all  portions  of  the  specification  synta.x  tree  be  defined. 
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(defobject  FC-SPEC  function  (db : set (term* ) ,  rb: set (rule*))  ;  set(term*)  = 
for*  (cs,  db  =  db,‘  cs-elt,  r,  e) 

cs  {  <r,  e>  I  (r,  e)  r  6  rb  A  e  e  match-rule(r ,  db)  > 
while  cs  ^  O. 

cs-elt  «—  conflict-resolution(cs) , 
r  ♦-  cs-elt. 1,  e  <—  cs-elt. 2, 
db  db  with  instantiate (r. rhs ,  e) 
returns  db) 

(defobject  MATCH-RULE  function  (db -.set (term*)  ,  r:rule*)  ;  dsubst*  * 
rep({e  |  (e)  V(p)  (p  €  r.lhs  »> 

(3(d)  (d  €  db  A  instantiate (p,  e)  =  d)))>)) 

(defobject  CONFLICT-RESOLUTION  function  (cs:  set(any-type) )  :  any-type  = 
arb(cs) ) 

(defobject  REP  function  (es :set(subst*))  :  dsubst*) 


Figure  5-6:  Rule  System  Specification  (Iterative  Version). 


The  iterative  “for*”  construct  used  in  Figure  5-6  is  part  of  the  language  used  in 
KIDS,  but  is  not  currently  implemented  in  Refine.  Therefore,  I  have  reformulated  the 
specification  tail  recursively.  See  Figure  5-7. 

As  in  Chapters  3  and  4,  this  chapter  will  focus  on  the  implementation  of  match- rule. 
(This  is  also  the  only  portion  of  the  specification  in  Figure  5-7  that  cannot  be  simply 
translated  into  Lisp  by  the  Refine  compiler.) 

The  transformations  used  in  the  initial  implementation  are  shown  in  Figure  5-S.  A 


(defobject  FC-SPEC  function  (db:set(term*) ,  rb:set(rule*) )  :  set(term*)  = 
let  (cs  =  •(  <r,  e>  |  (r,  e)  r  €  rb  A  e  G  match-rule(r ,  db)  }) 
if  cs  ^  O 

then  let  (cs-elt  «  conflict-resolution(cs)) 
let  (r  *  cs-elt. 1,  e  ■  cs-elt. 2) 

fc-spec(db  with  instantiate(r . rhs ,  e) ,  rb) 

else  db) 


Figure  5-7;  Rule  System  Specification  (Tail  Recursive  Version). 
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(def object  UNIVERSAL-TO-INTERSECTION*  rule  (a) 

a  a  ®expr  |  ($varsl)  V(y)  (y  €  ®S  =>  ©formula)  >’ 

— > 

a  =  ‘ Intersection* (  {  {©expr  |  ($varsl)  (©formula)}  |  (y)  y  €  ©S  >  )  ’  ) 

(def object  EXISTENTIAL-TO-UNION*  rule  (a) 

a  »  ©expr  |  ($var3l)  3(y)  (y  6  ©S  A  $other-cjs)  >’ 

— > 

a  a  ‘Union*(  {  {©expr  |  (Ivarsl)  A ($other-cjs)}  |  (y)  y  €  ©S  }  )  ’  ) 

(defobject  INTERSECTION*-TO-REDUCE-INTERSECTIOM  rule  (a) 
a  a  ‘ Intersection* (©S) * 

— > 

a  a  ‘ReduceC’n,  fiS)’) 

(defobject  UNIQN*-TQ-REDUCE-UNION  rule  (a) 
a  a  ‘ Union* (©S)’ 

— > 

A  a  ‘Reduce(’U,  ©S)’) 

(defobject  INSTANTIATE- TO-MATCH  rule  (a) 

a  a  ‘rep({  e  ]  (e)  instantiateOp,  e)  a  ©d  })  ’ 

— > 

a  a  'match(©p,  ©d)’) 

(defobject  REP-UNION- TO-DSUBST- JOIN-REP  rule  (a) 
a  a  ‘rep(©Sl  U  ©S2) ’ 

— > 

a  a  ‘DSUBST-JOIN(rep(©Sl),  rep(©S2))) 

(defobject  REP-INTERSECTION-TO-DSUBST-MEET-REP  rule  (a) 
a  a  ‘rep(©Sl  fl  ©S2)’ 

— > 

a  a  ‘DSUBST-MEET(rep(©Sl),  rep(©S2))) 


Figure  5-8:  Transformations  for  Initial  Implementation. 


transformation  is  implemented  as  an  object  of  type  rule.^  Its  single  argument  is  a  node 
in  a  Refine  syntax  tree.  The  syntax  . . .  — >  . . .  specifies  that  if  the  value  on  the  left 

side  of  the  arrow  is  true,  then  the  expression  on  the  situation  described  on  the  right  side 
of  the  arrow  is  actualized.^  In  Refine’s  rule  pattern  syntax,  symbols  beginning  with  •‘©'’ 


^Refine’s  rul«,  not  the  rule*  used  in  the  program  being  derived  here 

'‘Obviously  this  can  only  be  accomplished  for  a  restricted  set  of  right  side  conditions.  Refine  can 
handle  conditions  that  require  modifying  a  stored  value,  e.g.  destructively  modifying  a  structure  in 
memory  to  contain  a  specified  value.  Here  the  condition  a  ■  ...  is  achieved  by  destructively  modifying 
the  portion  of  the  syntax  tree  on  which  the  rule  was  invoked. 
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are  variables  that  match  a  single  program  term,  and  symbols  beginning  with  “$”  are 
variables  that  match  a  sequence  of  program  terms. 

The  first  two  rules  in  this  figure  transform  expressions  involving  universal  and  ex¬ 
istential  quantifiers  into  equivalent  expressions  involving  unary  intersection  and  union. 
(These  transformations  can  be  viewed  as  homomorphisms  from  Boolean  algebra  to  set 
algebra.)  The  next  two  rules  implement  unary  intersection  and  union  using  reductions  of 
the  corresponding  binary  operations.  These  first  four  rules  are  domain  independent.  The 
next  three  rules  are  specific  for  this  problem  domain.  The  first  expresses  the  specification 
for  the  primitive  match  function.  The  last  two  rules  express  the  homomorphism  of  the 
representation,  from  unions  and  intersection  of  sets  of  substitutions,  to  operations  in  the 
disjunctive  substitution  lattice. 

The  result  of  applying  these  transformations  to  the  match-rule  specification  in  Fig¬ 
ure  5-6  is  the  implementation  shown  in  Figure  5-9,  which  corresponds  to  the  implemen¬ 
tation  derived  in  Chapter  3. 

In  the  next  section  this  initial  implementation  will  be  optimized  using  finite  difference 
and  partial  evaluation  transformations.  Before  performing  these  transformations,  it  will 
be  convenient  to  perform  a  program  folding  step.®  The  rest  of  this  section  describes  this 
step. 

One  problem  that  arises  in  many  symbol  manipulation  systems,  such  as  program 
transformation  systems  and  computer  algebra  systems,  is  intermediate-expression  blow- 

®The  transformation  that  replaces  a  call  to  a  function  by  the  inline  expansion  of  the  program  body 
is  known  as  unfolding.  The  inverse  transformation  is  known  eis  folding. 


(defobject  MATCH-RULE  function  (db:  setCterm*) ,  r:  rule) 

:  dsubst*  a 

reduce ( ’ dsubst-meet , 

image((A(p)  reduceC Msubst-join,  image((A(d)  match(p,d)), 

db))), 


r.lhs))) 


Figure  5-9:  Initial  Implementation  of  Match-Rule. 
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up.  The  intermediate  results  that  arise  in  these  systems,  though  correct,  can  become 
overly  complex,  taxing  the  resources  of  both  the  computer  and  the  user.  Ideally,  symbol 
manipulation  systems  might  be  designed  to  help  minimize  this  problem.  For  now,  manual 
methods  will  be  used. 

A  small  example  of  expression  blow-up  that  occurs  here  can  be  solved  by  manual 
program  folding.  The  initial  implementation  in  Figure  5-9  consists  of  calls  to  dsubst-join 
nested  inside  of  calls  to  dsubst-meet.  It  turns  out  to  be  convenient  to  fold  the  sections 
of  the  code  containing  the  calls  to  dsubst-join.  This  will  simplify  the  transformations 
needed  in  the  next  section.  The  result  of  this  folding  is  shown  in  Figure  5-10.  The  new 
function  is  called  match-elt-set  because  it  matches  a  pattern  against  all  of  the  elements 
of  a  set  and  returns  a  disjunctive  substitution  summarizing  the  results. 

5.4  Optimization 

This  section  presents  transformations  to  (partially)  implement  the  optimizations  de¬ 
scribed  in  Chapter  4.  Note  that  whereas  the  programs  in  Chapter  4  explicitly  manipulate 
the  vectors  L  and  R  element  by  element,  the  functional  programs  in  this  section  are  re¬ 
stricted  to  manipulating  entire  sets  and  sequences.  The  next  two  subsections  describe 
the  finite  differencing  and  partial  evaluation  optimizations. 

(defobject  MATCH-RULE  function  (db:  setftenn*),  r:  rule) 

:  dsubst*  = 
reduce(’dsubst-meet, 

ioage((A(p)  match-elt-eetCp,  db)), 
r.lhs))) 

(defobject  MATCH-ELT-SET  function  (p:  term*,  s:  sat (term*)) 

:  dsubst*  ■ 

reduce( 'dsubst-join,  image((A(d)  match(p,d)), 

s))) 

Figure  5-10:  Match-Rule  after  Folding  Match-Elt-Set. 
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5.4.1  Finite  Differencing 

The  main  optimization  involves  incrementally  updating  the  conflict  set  as  changes  are 
made  to  the  database.  Assume  that  the  system  has  just  modified  the  database  by  adding 
a  new  datum,  and  is  now  computing  the  new  conflict  set  by  matching  all  of  the  rules 
against  the  new  database.  Incremental  updating  involves  reusing  the  intermediate  results 
from  the  previous  cycle  in  generating  this  new  conflict  set. 

The  key  to  this  optimization  lies  in  factoring  the  expression  for  the  new  value  of  the 
conflict  set  into  (1)  terms  involving  the  previous  conflict  set  computation,  and  (2)  terms 
involving  the  newly  added  datum.  In  addition  to  this  factoring,  “bookkeeping”  code  is 
needed  to  store  the  results  from  the  previous  cycle  for.  use  in  the  next  cycle.  This  can 
be  seen  in  the  use  of  the  L(eft)  and  R(ight)  vectors  in  lines  13-20  in  the  program  in 
Figure  4-4.  In  the  current  implementation,  only  the  first  of  these  tasks,  the  factoring, 
has  been  carried  out.® 

This  factoring  is  accomplished  as  follows.  Assume  that  the  system  has  just  added 
some  new  data  (db)  to  the  previous  contents  of  the  database  {db)J  The  task  is  now  to 
compute  the  conflict  set  for  this  new  database.  For  a  given  rule  this  can  be  expressed  as 
computing  match-rule(d6  U  d6).  (See  Figure  5-11.)  The  requirement  that  the  program 
be  incremental  involves  separating,  as  much  as  possible,  the  computations  involving  db 
from  the  computations  involving  db.  In  the  final  program  all  computations  involving 
db  U  db  will  be  separated  into  computations  involving  db,  and  computations  involving  db. 
The  motivation  is  that  the  values  involving  db  will  be  saved  from  the  previous  cycle  of 
the  interpreter,  and  the  computations  involving  db  will  be  relatively  fast  since  the  sets 
manipulated  will  be  small  (compared  with  the  sets  generated  in  matching  db,  which  is 
assumed  to  be  much  larger  than  db). 

®Compare  this  division  to  the  separation  of  functional  portions  of  code  from  portions  of  code  involving 
state  in  [1]. 

^Though  the  rule  system  specification  that  we  have  been  using  only  requires  adding  a  single  datum 
to  the  database  at  a  time,  in  actuality  it  is  more  efficient  to  add  several  new  data  at  a  time.  Therefore, 
the  formulation  here  has  been  generalized  to  deal  with  adding  a  set  of  new  data  to  the  database. 


(defobject  FD-PE-SPEC  fiinction  (db-old: set (term*) ,  db-delta: setCterm*) ) 

:  dsubst*  ■ 

match-rule(<  {  [’f,  ’-x],  [’g,  ’-y],  C’h,  ’-x,  ’-y]  >, 

C’P.  '-X.  '-y]  >. 
db-old  U  db-delta)) 

Figure  5-11:  Specification  for  Optimized  Matcher. 

The  rules  needed  for  finite  differencing  involve  the  distribution  of  U  over  the  union  of 
db  and  d6,  and  of  □  over  U.®  Some  of  these  rules  are  shown  in  Figure  5-12. 

Performing  the  source-to-source  transformations,  from  initial  implementation  to  finite- 
differenced  code,  requires  several  low-level  rules  similar  to  REP-REDUCE-UNION-TO-REDUCE — 
DSUBST-JOIN-REP  in  Figure  5-12.  In  general,  any  mathematical  property,  such  as  a  homo- 

^Corresponding,  respectively,  to  the  Right  memories  and  the  Left  memories  in  Chapter  4. 


(defobject  LEMMA-DISTRIBUTE-MATCH-ELT-SET-OVER-UNION  rule  (a) 
a  *  *match-elt-set(fip,  fiSl  U  fiS2) ’ 

A  p2  *  c-t(p) 

— > 

a  ■  ‘match-elt-set(®p,  ®S1)  U  match-elt-set(0p2,  fflS2)’) 

(defobject  DISTRIBUTE-DSUBST-MEET-OVER-DSUBST-JOIN  rule  (a) 
a  »  ‘dsubst-meet(aSl ,  dsubst-join(®S2,  ®S3))’ 

--> 

a  *  * dsubst- join(dsubst-nieet(fiSl ,  ®S2) ,  dsubst-meet(®Sl ,  ®S3))’) 

(defobject  DISTRIBUTE-SETFORMER-OVER-UNION-OF-DOMAINS  rule  (a) 
a  »  ®expr  |  (y,  $varsl)  y  €  ®S  U  ®R  A  $other-cjs  >' 

A  expr2  *  c-t(expr) 

— > 

a  ■  ®expr  (  (y,  $varsl)  y  6  ®S  A  $other-cjs  > 

U  {  ®expr2  |  (y,  $varsl)  y  C  ®R  A  $other-cjs  }*) 

(defobject  REP-REDUCE-UNION-TO-REDUCE-DSUBST- JOIN-REP  rule  (a) 
a  *  ‘rep(  reduce(’U,  image((A  ($varsl)  ®expr) ,  ®S)))' 

— > 

a  *  ‘reduce( 'dsubst- join,  image((A  ($varsl)  rep(®expr)),  ®S))’) 


Figure  5-12:  Finite  Differencing  Transformations. 
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morphism  or  a  distributive  law,  can  be  used  to  generate  several  different  syntactic  rules. 
Ideally,  we  would  like  to  be  able  to  enter  the  mathematical  properties  — the  homomor- 
phisms  and  distributive  laws — directly,  and  have  a  simple  automated  theorem  proving 
component  synthesize  the  specific  low-level  rules  needed.  For  example,  the  REP-REDUCE — 
UNION-TO-REDUCE-DSUBST- JOIN-REP  rule  in  Figure  5-12  should  be  easily  derivable  from  the 
REP-UNION-TO-DSUBST-JOIN-REP  rule  in  Figure  5-8.®  For  now,  we  will  enter  these  rules 
manually.  (And,  in  the  current  status  of  the  implementation,  some  of  the  transformations 
have  been  performed  manually.) 

As  mentioned  above,  the  development  can  be  simplified  by  folding  match-elt-set 
(see  Figure  5-10),  and  expressing  the  transformations  in  terms  of  this  function.  For 
example,  the  distributive  property  of  dsubst-join  over  union,  can  be  expressed  as  a 
lemma  involving  distributing  match-elt-set  over  union  (shown  in  Figure  5-12).  This 
greatly  reduces  the  number  of  steps  required  in  the  derivation,  and  makes  the  final  code 
(shown  in  Figure  5-14)  more  concise. 

5.4.2  Partial  Evaluation 

The  Rete  matcher  involves  a  dataflow  network  of  matching  nodes,  as  described  in  Chap¬ 
ters  2  and  4.  This  network  can  be  automatically  generated  by  partially  evaluating  the 
initial  implementation  in  Figure  5-10.  This  partial  evaluation  replaces  the  run-time  it¬ 
eration  of  the  lattice  operations  over  the  elements  in  the  left  hand  side  of  the  rule,  with 
a  compile-time  expansion  of  the  call  tree  for  each  rule. 

The  partial  evaluation  is  conducted  by  substituting  the  fixed  value  for  the  LHS  of  the 
rule  into  the  call  to  match  rule,  and  simplifying  the  resulting  program.  These  simplifica¬ 
tions  are  performed  by  propagating  constant  values  up  through  the  code.  For  example, 
the  expression 

®The  automated  generation  of  transformations  required  here  might  not  be  too  difficult.  For  e.xample, 
the  transformation  needed  here  could  have  been  provided  if  for  every  rule  involving  a  homomorphisms 
on  associative  binary  operations,  a  rule  generalizing  this  homorphism  to  reductions  of  these  operation 
on  sets  of  values  could  be  automatically  generated. 
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(defobject  PARTIAL-EVALUATE-IMAGE-OF-LAMBDA-ON-LITERAL-SET  rule  (a) 
a  ■  ‘imageCfif,  {$elts}) ' 

— > 

a  *  KimageCCA  Celt)  make-termCc-tCf ) ,  [elt] ) ) ,  alts))  >’) 

(def object  REDUCE-BINOP-OF-LITERAL-SET  rule  (a) 
a  »  *  reduce (®binary-op,  {fix,  $y}) ’ 

— > 

replace  a  by  make-term(c-t (binary-op) ,  [c-t(x), 

‘reduce(fl(c-t(binary-op)) , 
{$(c-tset(y))}) ’])) 

(def object  REDUCE-SINGLETON  rule  (a) 

a  ■  *reduce(®f,  ®a) '  A  8ingleton-literalfonner(s) 

A  X  =  the-literal-axpr(a) 

— >  replace  a  by  c-t(x)) 


Figure  5-13:  Partial  Evaluation  Transformations. 


image((A(p)  match-elt-set(p,  db)),  [pi,  p2,  p3]) 
can  be  simplified  to 

[match-elt-8et(pl,  db) ,  match-elt-8et(p2,  db) ,  match-elt-8et(p3,  db)] 

using  the  partial  evaluation  rules  shown  in  Figure  5-13.  These  rules,  along  with  many 
other  simplification  rules,  are  provided  by  the  simplification  facility  in  the  KIDS  system. 

The  effect  of  both  finite  differencing  and  partial  evaluation  is  demonstrated  by  the 
transformation  of  the  specification  shown  in  Figure  5-11.  This  specification  represents 
matching  a  particular  rule  against  a  database  db  with  an  incremental  update  db-delta. 
The  result  of  applying  the  finite  differencing  rules  and  the  partial  evaluation  rules  to  this 
specification  is  shown  in  Figure  5-14. 

This  resulting  code  corresponds  to  an  expansion,  for  a  3-pattern  rule,  of  the  incre¬ 
mental  matcher  described  in  Equation  4.11.  The  correspondence  between  the  calls  to 
match-elt-set  in  this  program  and  the  values  of  the  Right  memory  vector  in  Chapter  4 
is  as  follows: 


/?3  =  match-elt-set([’f ,  ’-x],  db), 
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(defobject  MATCH-RULE  function  (db:  set(tenn*),  db-delta:  setCterm*)) 

:  setCsubst*)  • 

dsub8t-m««t(match-«lt-s«t( ['f ,  '-x],  lb), 

dsubst-meet(match-elt-set([’g,  ’-y],  db) , 

match-elt-set( [’h,  ’-x,  ’-y],  db))) 

U  dsub8t-m«at(match-«lt-8«t( ['f ,  '-x],  db) , 

d8Ub8t-meet(match-elt-8et( C’g,  ’-y],  db-delta), 
match-elt-8et( C’h,  ’-x,  ’-y],  db)) 

U  d8ub8t-maet(match-elt-8et( C'g,  ’-y],  db) , 

match-elt-8et( [’h,  ’-x,  ’-y],  db-delta)) 

U  d8ub8t-meet(match-elt-8et( C’g,  ’-y],  db-delta), 

match-elt-8et( [*h,  ’-x,  *-y],  db-delta))) 

U  daub8t-maat(match-elt-8et( C’f ,  ’-x],  db-delta), 

dsub8t-meet(match-elt-8et( C’g,  ’-y],  db) , 

match-elt-8et( C’h,  ’-x,  ’-y],  db))) 

U  dsub8t-meet(match-elt-set(C’f .  ’"x],  db-delta), 

d8Ubst-meet (match-alt-set ( C’g.  ’“y],  db-delta), 
match-elt-8et( C’h,  ’-x,  ’-y],  db)) 

U  dsub8t-meet(match-elt-set( C’g.  ’-y].  db) . 

match-elt-setC C’h,  ’-x,  ’-y],  db-delta)) 

U  dsubst-meet(match-elt-set( C’g.  ’-y].  db-delta), 

match-elt-setC C’h,  ’-x,  ’-y],  db-delta)))) 


Figure  5-14:  Final  Match-Rule  Implementation. 
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i?3  =  match-elt-set(C*f ,  ’-x],  db-delta), 

i?2  =  matchi-elt-setCC’g,  ’-y],  db), 

i?2  =  match-elt-sat([*g,  *-y],  db-delta), 

Rx  =  match-elt-setC [’h,  *-x,  ’-y],  db), 

Rx  =  match-elt-set([’h,  *-x,  ’-y],  db-delta). 

Using  this  correspondence,  the  program  in  Figure  5-14  can  be  rewritten  as 

Z3  =  (iZa  n  (i22  -^i) 

u  {R3n[{R2nRx)(j{R2nRx)i){R2nRx)] 
u  (R3n(R2nRx) 

u  (iZ3n[(iZ2niZi)u(/Z2ni?i)u(i?2n/?i)], 

which  is  the  same  expression  obtained  by  expanding  Equation  4.11  for  i  =  3. 

The  remaining  step  for  converting  this  program  into  a  Rete  network  is  the  addition 
of  the  bookkeeping  code  alluded  to  above. 

5.5  Future  Work 

This  section  briefly  v...  _sses  two  directions  for  extending  this  implementation, 

5.5.1  Automatic  Synthesis  of  Primitive  Functions 

One  possible  future  direction  for  this  implementation  is  the  automatic  synthesis  of  the 
primitive  functions  described  in  Section  5.2.  Simple  recursive  functions,  similar  to  match 
and  instantiate,  have  been  automatically  synthesized  using  the  synthesis  component  of 
KIDS  [30].  Structural  recursions  such  as  these  can  be  fully  characterized  by  their  re¬ 
cursive  and  base  cases,  as  described  in  Section  5.2.  These  descriptions  contain  most  of 
the  information  necessary  to  automatically  derive  these  functions.  Unfortunately,  it  was 
not  possible  to  perform  this  synthesis  in  the  current  version  of  KIDS,  since,  at  present. 
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the  synthesis  component  can  only  handle  recursions  that  terminate  in  a  single  base  case, 
whereais  the  structural  recursions  for  match  and  instantiate  have  two  base  cases:  con¬ 
stants,  and  variables. 

The  remaining  primitive  functions  are  the  lattice  operations  subst-meet,  dsubst-meet, 
and  dsubst-join.  In  Chapter  3,  all  of  the  information  required  to  describe  these  functions 
is  derived  from  the  descriptions  of  the  Substiutution  Semi-Lattice  and  the  Disjunctive 
Substitution  Lattice.  One  possibility  for  automatically  synthesizing  is  to  automatically 
verify  the  derivation  in  Chapter  3  using  a  symbolic  algebra  system,  perhaps  using  alge¬ 
braic  techniques  similar  to  those  in  [4]. 

5.5.2  Automatic  Control  of  Transformations 

Another  future  direction  for  this  implementation  is  in  the  area  of  automatic  control  of 
transformation  application.  The  application  of  the  transformations  in  this  chapter  has, 
for  the  most  part,  been  manually  directed.  Though  even  manually  directed  transfor¬ 
mational  programming  has  advantages  over  manual  program  writing — e.g.  correctness 
assurances — ultimately  we  would  like  the  system  to  direct  the  use  of  the  transforma¬ 
tions.  For  example,  KIDS  currently  has  tactics  to  direct  the  synthesis  of  simple  divide 
and  conquer  algorithms  and  simple  global  search  algorithms. 

One  technique  for  automating  the  use  of  transformations  is  to  design  a  set  of  trans¬ 
formations  that  when  exhaustively  applied^®  to  a  given  source  text  will  derive  the  desired 
result.  This  should  be  possible  for  the  transformations  in  Section  5.3  since  the  derivation 
proceeds  in  a  straight  progression  from  terms  involving  compound  logical  expressions  in 
set-formers,  to  terms  involving  set  union  and  intersection,  and  finally  to  terms  involving 
the  lattice  operations. 

Finally,  work  is  currently  being  conducted  on  general-purpose  finite-differencing  and 
partial-evaluation  facilities  to  enable  the  automation  of  the  optimizations  performed  in 
Section  5.4. 

repeatedly  applied  until  none  are  applicable 


60 


Chapter  6 


Discussion 


This  chapter  discusses  the  lessons  learned  from  this  work,  describes  the  progress  made, 
identifies  future  directions  to  pursue,  and  describes  the  place  of  this  thesis  in  the  context 
of  the  related  literature. 

Section  6.1  discusses  the  relationship  between  the  structures  introduced  in  the  deriva¬ 
tion  and  the  structures  used  in  the  model-theoretic  semantics  of  first-order  logic.  This 
section  briefly  mentions  some  advantages  of  using  algebraic  techniques  for  software  de¬ 
velopment.  Section  6.2  discusses  possible  future  directions  for  this  research.  Section  6.2.1 
discusses  short-range  directions,  such  as  addressing  the  simplifications  in  the  derivation 
and  implementation.  Section  6.2.2  discusses  long-range  prospects,  such  as  building  a 
comprehensive  library  of  programming  knowledge.  Section  6.3  discusses  the  related  liter¬ 
ature,  and  describes  how  this  thesis  contributes  to  this  literature.  Section  6.4  summarizes 
the  conclusions  of  this  thesis. 


6.1  Correspondence  to  Model  Theory 

This  section  discusses  the  correspondence  between  the  structures  used  in  the  derivation 
described  in  Chapter  3  and  the  structures  used  in  the  model-theoretic  semantics  of  first- 
order  logic.  (Appendix  A. 2  presents  a  very  brief  review  of  basic  model  theory.) 
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This  direct  relationship  between  the  domain  structures  and  the  implementation  struc¬ 
tures  yields  many  advantageis.  It  enables  us  to  explain  and  (in  principle)  to  verify  the 
features  implemented  so  far,  and  provides  clear  directions  for  implementing  extensions. 

Let  us  consider  the  analogy  between  a  rule  system  with  database  db  and  rulebase  rb, 
and  a  first  order  language  L  with  a  model  structure  whose  universe  is  U.  Identify  the 
database  db  with  the  universe  U,  and  consider  the  LHS  of  the  rule  to  be  a  conjunction 
of  terms  in  L.  In  this  view,  the  set  of  matches  for  the  LHS  in  db  consists  of  the  set  of 
valuations  <t,  with  universe  C/,  such  that  LHS^  =  T.  (Where  T  denotes  truth.)  That  is, 
the  problem  of  finding  all  matches  for  a  rule  in  a  database  can  be  seen  as  the  problem  of 
finding  all  possible  assignments  to  the  variables  in  a  conjunctive  term  under  which  the 
term  has  an  interpretation  in  a  given  universe. 

Interpreting  the  rule  system  in  this  way,  the  following  interpretations  can  be  given  to 
the  structures  used  in  Chapter  3: 

•  The  semi-lattice  SSL  consists  of  valuations;  ^  is  an  ordering  on  valuations;  and  fl* 
is  a  binary  operation  on  valuations. 

•  The  lattice  DSL  consists  of  sets  of  valuations;  C  is  an  ordering  on  sets  of  valuations; 
and  n  and  U  are  binary  operations  on  sets  of  valuations. 

•  The  procedure  match-rule  takes  a  LHS,  and  a  universe  db,  and  returns  the  maximal 
valuation,  under  from  the  set  {<t  |  LHS'^  =  T}. 

This  correspondence  provides  us  with  a  clear  semantics  for  the  Rete  algorithm  in 
terms  of  the  usual  model-theoretic  semantics  of  first-order  logic. 

This  correspondence  also  provides  a  directions  for  implementing  the  extensions  out¬ 
lined  in  Section  2.4.  For  example,  the  facility  for  handling  negated  patterns  in  the  Left 
Hand  Side  of  a  rule  can  be  obtained  by  directly  implementing  the  interpretation  for  nega¬ 
tion  in  the  semantic  definition  shown  in  Appendix  A. 2.  In  this  definition,  a  predication 
P{ti, . . .  ,tn)  is  true  under  a  valuation  <7  iff  the  tuple  of  its  arguments,  under  the  valuation 
(7,  is  an  element  of  the  relation  i.e. 
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T  if 

±  otherwise 


The  semantic  definition  also  indicates  that  a  negation  of  a  term  a  is  true  if  and  only  if 
the  term  is  false,  i.e. 


= 


T  if  a''  =  X 
X  otherwise 


Therefore,  a  negated  predication  is  true  iff  the  tuple  of  its  arguments  is  not  an  element 
in  the  corresponding  relation  in  the  model,  i.e. 


(^p(tx,...,t„)r  = 


T  if  (tf,...,0 
X  otherwise 


The  direct  implementation  of  this  specification  consists  in  matching  a  negated  pattern 
. . . ,  (which  represents  a  negated  predication)  iff  there  does  not  exist  a  valuation 
under  which  the  pattern  P{ti,. . . ,  t„)  is  true,  i.e.,  iff  there  does  not  exits  a  binding  to  the 
variables  in  P(ti,. . . ,  ^n)  under  which  P(ii,  ...,/„)  matches  an  element  in  the  database. 
This  corresponds  exactly  to  the  closed  world  assumption  described  in  [22]. 


6.2  Future  Work 

This  section  describes  possible  directions  for  future  research.  The  first  two  subsections 
decribe  relatively  short-range  directions  based  on  extending  the  derivation  to  include 
more  of  Rete’s  features,  and  completing  the  implementation.  The  second  section  describes 
some  longer-range  prospects. 

6.2.1  Coverage  of  Features  in  Rete 

Section  2.4  discussed  several  features  of  Rete  that  were  not  covered  in  the  derivation 
in  this  thesis.  Section  6.1  has  already  discussed  incorporating  one  of  these  features, 
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matching  for  negated  patterns,  into  the  derivation.  This  section  considers  incorporating 
the  remaining  features  into  the  derivation. 

Updating  the  conflict  set  as  data  are  removed  from  the  database  could  be  accom¬ 
plished  by  distributing  the  match  computation  over  set-difference,  as  well  as  over  set- 
union.  Distributive  laws  for  set-difference  could  easily  be  added  to  the  distributive  laws 
for  set-union  used  in  the  optimizations  in  Chapter  4. 

The  complexity  in  updating  the  conflict  set  as  data  are  removed  from  the  database 
arises  from  the  difference  between  adding  an  item  to  a  collection  and  removing  an  item 
previously  added  to  a  collection.  Adding  the  matches  for  new  data  to  the  conflict  set 
does  not  require  reference  to  any  past  information  about  the  database  or  conflict  set.  All 
of  the  information  required  is  contained  in  the  Left  and  Right  memories.  These  encode 
the  information  from  matches  between  component  patterns  and  objects  currently  in  the 
database,  and  are  used  to  compute  resulting  conjunctive  matches  that  include  the  new 
data  being  added  to  the  database.  When  a  new  datum  is  added  to  the  database,  new 
substitutions  can  simply  be  added  to  these  memories.  (Assuming  that  the  set-adjoin 
function  can  avoid  adding  duplicate  elements,  if  the  programmer  chooses  to  represent 
sets  as  irredundant  sequences.) 

However,  removing  an  element  previously  added  to  a  collection  requires  either  (1) 
maintaining  a  reference  to  that  object,  or  (2)  searching  through  the  entire  collection 
to  remove  all  elements  that  match  a  given  description.  The  second  approach  is  very 
inefficient,  and  would  cancel  the  benefits  of  having  an  incremental  matcher.  Therefore, 
the  technique  of  choice  is  to  maintain  information,  for  each  substitution  in  the  network, 
about  which  data  were  matched  in  the  derivation  of  that  substitution.  This  information 
can  be  used  by  the  system  to  update  the  network  when  a  datum  is  retracted.  This 
update  is  performed  by  removing  from  the  network  all  substitutions  that  were  derived 
using  the  datum  being  removed.  In  Rete,  this  is  implemented  by  storing,  with  each 
token  in  the  network,  references  to  the  data  used  in  its  generation.  This  could  also  be 
implemented  using  a  dependency  maintenance  system.  This  dependency  technique  is 


used  in  the  AMORD  rule  system  [9]. 

The  sharing  of  computations  between  rules  could  Y  e  handled  by  performing  straight¬ 
forward  common  subexpression  removal  between  the  matching  code  generated  for  the 
separate  rules. 

6.2.2  Implementation 

The  derivation  described  in  Chapters  3  and  4  was  only  partially  implemented  in  the  KIDS 
system.  This  section  briefly  discusses  some  future  possibilities  for  this  implementation. 

It  should  be  possible  to  synthesize  match  and  instantiate  using  Smith’s  Divide- 
and-Conquer  tactic.  This  is  not  possible  at  present  because  the  tactic  can  only  handle 
recursions  with  one  base  Ccise,  whereas  the  recursions  on  s-expressions  in  match  and 
instantiate  have  two  base  cases  (variables  and  constants).  If  KIDS  were  extended  to 
handle  recursions  with  multiple  base  cases,  this  synthesis  could  be  performed.  The  two 
base  cases  in  the  representation  of  s-expressions  also  proved  a  problem  for  Refine,  since 
it  does  not  currently  support  union  types. 

The  finite-differencing  in  Chapter  5  was  performed  using  explicit  transformations. 
Work  is  currently  underway  to  expand  the  KIDS  finite-differencing  facility.  This  may 
enable  the  system  to  perform  the  finite  differencing  in  Chapter  5,  and  to  handle  the  finite 
differencing  over  deletions  to  the  database  that  is  required  to  implement  retraction. 

Many  of  the  transformations  used  in  the  derivation  could  be  implemented  as  the¬ 
orems  in  the  Rainbow  theorem  prover[31],  (rather  than  being  represented  as  syntactic 
transformations).  This  would  allow  for  more  flexible  use  of  these  rules. 

Finally,  the  performance  of  the  matcher  could  be  improved  by  some  simple  data 
structure  improvements.  For  example,  the  performance  of  subst-meet  could  be  vastly 
improved  if  it  were  possible  to  quickly  determine  when  two  substitutions  had  disjoint 
domains.  This  could  be  achieved  by  including,  in  the  implementation  of  a  substitution, 
a  bit-vector  representation  of  the  substitiution’s  domain.  This  would  allow  determining, 
in  constant  time,  if  two  substitutions  had  any  variables  in  common. 
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Figure  6-1:  Rule  System  Design  Space. 

6.2.3  Program  Design  Spaces 

The  origin  of  this  thesis  wa.s  in  a  more  ambitious  plan  by  the  author  to  formalize  all 
the  programming  knowledge  used  in  implementing  rule  systems.  This  thesis  represents 
a  detailed  formalization  of  a  small  part  of  this  design  space. 

The  overall  approach  involves  the  following  steps:  (1)  Examine  several  programs  from 
the  literature  that  belong  to  a  particular  application  domain,  e.g.  rule  systems.  (2)  Con¬ 
struct  a  taxonomy  of  these  programs,  based  on  the  different  design  decisions  that  they 
embody.  (3)  Rederive  these  programs  (or  simplified  versions  of  them)  using  formal  spec¬ 
ifications,  domain  models,  formally-defined  representations,  and  transformation  rules. 

The  goal  of  this  work  is  to  build  up  libraries  containing:  formal  domain  models, 
mathematical  structures  for  use  in  building  domain  models,  and  common  programming 
techniques  for  efficiently  implementing  these  structures. 

This  work  involves  an  attempt  to  map  out  the  design  space  of  rule  systems,  i.e.  the 
various  design  decisions  that  differentiate  the  programs  in  this  domain.  Figure  6-1  shows 
a  portion  of  the  rule  system  design  space. 

The  programs  in  this  space  share  a  common  domain  model,  but  differ  in  various 
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design  decisions  made.  For  example,  the  AMORD  system  is  a  forward  chaining  system 
like  OPS5,  and  also  implements  an  incremental  matching  scheme.  However,  the  AMORD 
system  differs  from  0PS5  in  the  technique  for  maintaining  the  partial  matches.  AMORD 
rules  cannot  directly  contain  conjunctive  patterns  in  their  LHS’s.  The  LHS’s  are  limited 
to  containing  a  single  pattern.  To  obtain  the  effect  of  conjunctive  patterns,  a  technique  is 
used  that  is  isomorphic  to  the  technique  of  Currying  in  mathematical  logic.  To  represent 
a  conjunct  of  patterns,  a  rule  is  specified  that  matches  the  first  pattern  of  the  conjunct, 
and,  as  a  RHS  action,  adds  a  new  rule  to  the  rulebase  that  handles  the  matching  of  the 
remaining  patterns.  This  is  repeated  recursively  until  all  of  the  patterns  in  the  conjunct 
have  been  matched.  For  example,  the  OPS5  rule 

(  {(/  ?i/),(A  ?a:  ?y)}  =?-  (p  ?a:  7y)  ) 

would  be  translated  into  the  AMORD  rule 

((/  ?a:)  =»  {{g  7y)  =>  {{h  7x  ?y)  (p  ?z  ?y)  ))). 

Another  example  of  differing  design  decisions  involves  indexing  the  patterns  in  the 
rulebase.  Instead  of  matching  a  new  datum  against  all  of  the  rule  patterns,  the  system 
can  first  use  a  quick  approximate  matcher  to  filter  out  rule  patterns  that  cannot  possibly 
match  the  datum.  Alternatives  for  this  quick  matcher  include  testing  if  the  predicate 
symbols  in  the  pattern  and  datum  are  identical,  testing  if  the  length,  or  nesting,  of  the 
pattern  and  datum  are  identical,  or  testing  if  the  constant  portions  of  the  pattern  and 
datum  are  identical. 

A  third  example  of  design  decisions  involves  mechanisms  for  handling  assumptions 
and  retraction.  Mechanisms  that  have  been  used  for  this  function  include  context  systems 
and  truth-maintenance  systems. 

Achieving  the  ultimate  goal  of  this  project  requires  both  the  high-level  mapping  of  the 
design  space  described  above,  and  the  detailed  formalization  and  implementation  of  the 
pieces  of  this  design  space.  This  thesis  presents  a  portion  of  this  detailed  formalization: 
a  beginning  for  the  section  dealing  with  the  formal  derivation  of  0PS5. 
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Though  it  is  very  time-consuming,  filling  in  these  design  spaces  with  formal  pieces 
such  as  the  one  in  this  thesis  appears  to  be  a  promising  direction  towards  building  up 
the  library  of  programming  knowledge  that  will  allow  us  to  progress  to  the  next  level  of 
programming  tools. 

6.3  Related  Work 

This  section  describes  work  related  to  this  thesis.  This  includes  include  references  for 
the  Rete  network;  research  on  formalizing  matching  and  unification;  research  on  program 
synthesis,  transformations,  and  automatic  programming;  and  general  work  on  utilizing 
formal  approaches  in  (manual)  softw'are  development. 

6.3.1  The  Rete  Matcher 

The  Rete  network  was  developed  by  Forgy  in  1974,  and  reported  on  in  [11].  A  more 
complete  presentation  can  be  found  in  Forgy’s  PhD  thesis  [12].  The  Rete  algorithm  is 
used  in  the  widely-used  0PS5  Production  System  language.  A  textbook  for  the  0PS5 
system  [5]  contains  a  chapter  on  the  Rete  algorithm.  However,  these  sources  do  not 
provide  a  concise  formal  description  of  the  algorithm,  a  formal  derivation  of  the  algorithm, 
or  a  correctness  proof. 

This  thesis  has  presented  a  formal  derivation  of  the  algorithm,  and  a  partial  imple¬ 
mentation  of  this  derivation,  using  correctness-preserving  transformations.  However,  this 
thesis  has  dealt  with  a  simplified  version  of  the  Rete  algorithm,  as  described  in  Chapter 
2  and  Sections  6.2.1.  It  has  focused  on  the  core  feature  of  Rete:  the  incremental  update 
of  the  conflict  set  as  the  database  is  modified.  The  derivation  and  structures  presented 
here  can  serve  as  a  framework  for  a  derivation  of  the  complete  Rete  system. 
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6.3.2  Matching  and  Unification 

This  thesis  has  studied  the  problem  of  determining  all  possible  matches  between  a  set  of 
conjunctive  patterns  (the  LHS  of  a  rule)  and  a  database,  and  of  incrementally  updating 
this  information  as  the  database  is  modified.  In  this  work,  the  relatively  simple  function 
for  matching  a  single  pattern  and  a  single  datum,  shown  in  Figure  5-3,  has  been  taken 
as  a  primitive.  An  approach  for  automating  the  derivation  of  this  single-pattern  single¬ 
datum  matcher  has  been  mentioned  in  Section  5.5.  This  section  will  discuss  research  on 
formalizing  the  single-pattern  single-datum  matching  problem,  and  a  generalization  of 
this  problem,  unification,  that  allows  both  pattern  and  datum  to  contain  variables. 

Unification  is  a  generalization  of  matching.  In  matching,  only  the  pattern  can  contain 
variables;  the  datum  must  be  a  ground  term.  Matching  requires  finding  a  substitution 
for  the  variables  in  the  pattern  that  make  it  equivalent  to  the  datum.  Unification  is  the 
analogous  computation  for  two  patterns  that  both  contain  variables.  As  in  matching, 
the  goal  is  to  find  a  single  substitution  under  which  both  terms  are  equivalent. 

There  is  a  body  of  literature  about  techniques  for  implementing  unification.  One  of 
the  earliest  references  to  unification  in  the  computer  science  literature  was  in  Robinson's 
description  of  resolution  theorem  proving  [26].  A  recent  summary  of  the  formalization  of 
unification  and  resolution  can  be  found  in  (27).  A  formalization  somewhat  similar  to  the 
formalization  in  this  thesis,  but  only  covering  the  single-pattern  single-datum  case,  can 
be  found  in  [10]. 

Manna  and  Waldinger  [17]  have  presented  a  detailed  formal  derivation  of  the  unifica¬ 
tion  algorithm.  Another  derivation  of  the  unification  algorithm,  published  by  Rydeheard 
and  Burstall  [28],  is  based  on  concepts  from  Category  theory. 

Recent  work  on  unification  has  centered  on  the  problem  of  constructing  unification 
procedures  that  incorporate  certain  equational  theories.  For  example,  in  a  rule  system 
dealing  with  arithmetic,  representing  each  fact  about  addition  requires  two  rules,  due  to 
the  commutativity  of  addition.  For  example,  the  identity  x  4-0  =  x  would  be  represented 
as  the  two  rules 
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(+  ?a;  0)  ?x 

(+  0  ?x)  ?x. 

It  would  be  preferable  to  program  the  matcher  to  treat  as  a  commutative  operator, 
and  to  allow  (+  ?x  0)  to  match,  for  example,  against  (+  0  (/  1)).  The  specific  problem  of 
incorporating  commutativity  and  associativity  into  a  matcher,  known  as  AC  Unification 
(Associative-Commutative  Unification),  has  received  much  attention  in  the  literature 
[34].  The  general  problem  of  adding  equational  theories  to  unification  algorithms  has 
also  been  addressed  [20]. 

6.3.3  Automatic  Programming  and  Transformations 

The  field  of  automatic  programming,  and  the  subfield  of  program  transformations,  are 
well  served  by  survey  articles  and  compilations  [24,  13,  14]. 

Two  pioneering  efforts  in  codifying  programming  knowledge  are  the  PhD  theses  of 
Barstow  [2]  and  Rich  [23].  Both  of  these  codifications  focused  on  the  domain  of  common 
data  structures  and  operations. 

The  derivation  in  Chapter  3  of  this  thesis  is  most  closely  related  to  the  work  on 
program  synthesis,  for  example  Smith’s  derivations  of  divide-and-conquer  algorithms  [30] 
and  global-search  algorithms  [32]. 

The  early  section  of  the  derivation  in  Chapter  3  is  concerned  with  translating  a 
logical  specification  into  an  executable  form.  The  general  problem  of  implementing  such 
logical  specifications  has  been  addressed  in  several  systems,  for  example,  the  AP5  system 
developed  at  ISI  [7],  and  the  CHI  system  developed  at  Stanford  [35].  (The  CHI  system 
was  a  predecessor  of  the  Refine  system  used  in  the  implementation  in  Chapter  5.) 

The  optimization  in  Chapter  4  is  related  to  the  work  on  program  optimization  using 
finite  differencing  begun  in  the  SETL  project  at  New  York  University  [19].  This  technique 
has  also  been  used  in  the  KIDS  system  used  in  the  implementation  in  Chapter  5  [31]  [33]. 
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This  thesis  was  conducted  as  part  of  the  Programmer’s  Apprentice  project  at  the  MIT 
Artificial  Intelligence  Laboratory  [25].  The  goal  of  this  project  is  to  build  an  intelligent 
apprentice  system  to  aid  programmers  in  all  phases  of  their  activity.  I  have  focused  on 
the  problem  of  creating  the  library  of  programming  knowledge  that  is  fundamental  to 
the  operation  of  any  such  system.  In  order  to  achieve  the  level  of  detail  and  precision 
necessary  for  formalization  and  automation,  this  thesis  has  focused  on  a  single  narrow 
program  domain.  Hopefully  the  ideas  presented  here  will  be  applicable  to  other  efforts 
in  the  overall  task  of  building  the  “complete  library  of  programming  knowledge.” 

6.3.4  Formal  Methods  in  Deriving  Programs 

In  addition  to  the  work  in  automatic  programming,  there  is  a  large  effort  in  computer 
science  to  increase  the  use  of  formal  methods  in  manual  software  development.  This  work 
is  often  associated  with  the  pioneering  work  of  Dijkstra,  Hoare,  and  many  others. 

One  approach  to  developing  a  formal  theory  of  programs  is  to  concentrate  on  func¬ 
tional  programs.  In  his  ACM  Turing  lecture[l].  Backus  discussed  constructing  an  algebra 
of  programs  using  the  functional  language  FP.  Functional  programs  have  the  advantage 
of  being  much  easier  to  reason  about  than  programs  with  state,  since,  like  mathematical 
objects,  functional  expressions  have  the  same  value  in  any  context.  However,  efficiency 
considerations  have  dictated  that  most  real-world  programming  heis  been  done  using  im¬ 
perative  languages.  In  [1],  Backus  presents  some  thoughts  about  combining  the  benefits 
of  functional  programming  with  the  eflBciency  of  imperative  programming. 

An  example  of  current  work  on  formalizing  an  algebra  of  (functional)  programs  is  the 
work  by  Meertens  [18]  and  Bird  [4].  The  aim  of  their  work  is  to  produce  mathematical 
theories  of  common  data  structures  and  their  operations.  For  example,  [4]  presents  a 
portion  of  a  theory  of  lists.  Both  the  work  in  [4],  and  the  FP  work  described  in  [1], 
deal  with  formalizations  of  common  data  structures  such  as  lists  and  sequences.  The 
derivation  in  Chapters  3  and  4  is  offered  as  an  example  of  applying  these  algebraic 
techniques  to  new  compound  data  structures  (SSL  and  DSL)  derived  for  a  particular 
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application  domain. 

The  derivation  in  this  thesis  belongs  to  a  tradition  of  formal  derivations  of  algorithms, 
such  as  those  published  in  the  journal  Science  of  Computer  Programming.  It  is  impor¬ 
tant  to  note  that  almost  all  of  these  formal  derivations,  including  the  one  in  this  thesis, 
have  been  done  after  the  fact.  The  preliminary  state  of  our  knowledge,  and  the  exigen¬ 
cies  of  programming  in  the  real  world,  do  not  usually  allow  the  luxury  of  using  formal 
derivation  for  writing  new  and  innovative  programs.  Perhaps  this  situation  will  change 
as  we  progress  in  our  experience  with  formal  methods.  Then  we  will  be  able  to  bring  the 
clarity  and  precision  of  our  best  presentations  of  programs  to  our  development  of  new 
programs.  I  hope  that  this  thesis  has  contributed  towards  this  goal. 

6.4  Conclusions 

This  thesis  has  analyzed  the  rule  system  matching  problem,  and  has  derived  a  simple,  but 
efficient,  implementation.  The  core  of  the  development  is  a  mathematical  model  of  the 
information  computed  and  manipulated  in  performing  this  task.  The  representations  used 
in  the  implementation  are  directly  derived  from  this  mathematical  model.  The  structures 
in  this  model  are  similar  to  the  valuation  structures  used  in  the  model-theoretic  semantics 
of  first-order  logic. 

My  attempt  to  formalize  this  model  has  led  me  to  introduce  disjunctive  substitutions 
to  represent  the  information  obtained  from  matching  the  patterns  of  a  rule  against  sev¬ 
eral  possible  data  in  a  database.  The  formal  derivation  of  the  matcher  is  bcised  on  a 
homomorphism  from  the  matcher  specification  to  a  lattice  formed  from  these  disjunctive 
substitutions. 

The  initial  implementation  has  been  optimized  based  on  distributive  properties  of  the 
representation.  Further  optimization  has  been  performed  using  partial  evaluation.  The 
resulting  program  has  been  shown  to  be  isomorphic  to  a  simplified  Rete  network. 
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This  derivation  can  be  summarized  schematically  as: 

Rete  =  Formal  Specification 

+  Lattice  Construction  based  on  Homomorphism  to  Specification 
+  Finite  Differencing  based  on  Distributive  Laws 
+  Partial  Evaluation. 

Both  the  initial  derivation  and  the  optimizations  have  been  (partially)  implemented 
using  program  transformations  in  the  Refine  wide-spectrum  language  and  the  Kestrel 
Interactive  Development  System. 

The  structures  introduced  in  the  above  program  derivation  have  been  shown  to  corre¬ 
spond  to  structures  used  in  developing  the  model-theoretic  semantics  of  first  order  logic. 
This  connection  provides  an  explanation  and  verification  of  the  algorithm,  and  provides 
directions  for  extending  it  into  a  more  complete  implementation. 

Though  the  type  of  formal  derivation  and  implementation  described  in  this  thesis 
can  be  extremely  time-consuming,  I  feel  that  it  hais  the  potential  for  automating  a 
significant  portion  of  programming-in-the-small.  Though  it  does  not  directly  address 
the  complexity  management  issues  that  dominate  programming-in-the-large,  perhaps 
after  rationalizing  the  development  of  small  software  components,  we  will  be  in  a  better 
position  to  address  the  large-scale  issues. 
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Appendix  A 

Mathematical  Definitions 

A.l  Lattice  Theory 

This  section  presents  some  standard  mathematical  definitions  for  lattices  and  related 
structures.  Some  of  these  definitions  are  used  in  the  derivation  in  Chapter  3.  Discussion 
of  this  material  can  be  found  in  many  algebra,  universal  algebra,  and  model  theory  texts, 
e.g.  [3]  [6]  [8]. 

A.  1.1  Sets,  Relations,  Posets 

Given  a  set  A,  the  power  set  of  A,  denoted  by  2'^,  is  the  set  of  all  subsets  of  A  (including 
the  empty  set,  and  A  itself). 

The  Cartesian  Product  of  a  finite  sequence  of  sets  Ai, . . . ,  An-,  denoted  by  Ai  x . . . 
is  the  collection  of  all  n-tuples  (ai, . . .  ,an)  with  Cj  6  Ai, . . . ,  a„  €  If  each  of  the  .4, 

is  identical  with  a  fixed  set  A,  we  write  A”  =  /Ij, . . . ,  An- 
.An  n-ary  relation  on  a  set  A  is  a  subset  of  A’'. 

A  partial  function  from  5  to  T  is  a  binary  relation  R  such  that  (x,y)  G  R  and 
(x,  z)  E  R  implies  y  =  z. 

The  domain  of  a  function  /,  denoted  by  dom(f),  is  {i  |  (3y  6  T){x,y)  €  R]- 
A  function  from  5  to  T  is  a  partial  function  with  domain  S. 
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An  n-ary  operation  on  a  set  5  is  a  function  /  :  5  x  . . .  x  5  — ^  5. 

An  algebra  is  a  finite  collection  of  n-ary  relations  and  n-ary  operations. 

A  poset  (partially  ordered  set)  is  a  set  A  with  a  binary  relation  <  such  that 

(Vx)  X  <  X 

(Vx,j/)  (x  <  yky  <  x)  =►  x  =  y 
(Vx,y,z)  (x  <  yky  <  z)  =>  x  <  x. 

These  equations  state  that  the  relation  is  reflexive,  antisymmetric,  and  transitive. 

A. 1.2  Semilattices  and  Lattices 

A  semilattice  is  a  poset  (A,  <}  with  a  binary  operation  A  (greatest  lower  bound)  on  the 
set  A  such  that 

(Vx,  y)  X  Ay  <  X 
(Vx,y)  X  Ay  <y 

(Vx,  y,  z)  (z  <  x)  &  (z  <  y)  =»•  z  <  I  A  y. 

The  first  two  equations  state  that  x  A  y  is  a  lower  bound.  The  third  equation  states 
that  X  A  y  is  the  greatest  lower  bound. 

A  lattice  is  a  poset  (A,  <)  with  two  binary  operations  A  (greatest  lower  bound)  and 
V  (least  upper  bound)  on  the  set  A  such  that 

(Vx,  y)  X  A  y  <  X 
(Vx,y)  X  A  y  <  y 

(Vx,  y,  z)  (z  <  x)  &  (z  <  y)  =»  z  <  X  A  y 
(Vx,  y)  X  V  y  >  I 
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(Vz,y)  xVy  >  y 

(Vx,y,^)  {z>x)k{z>y)=f^z>xyy. 

The  first  three  equations  state  that  z  Ay  is  the  greatest  lower  bound.  The  fourth  and 
fifth  equations  state  that  z  V  y  is  an  upper  bound.  The  sixth  equation  states  that  z  V  y 
is  the  least  upper  bound. 

A. 1.3  Distributive  Lattices  and  Boolean  Algebras 

A  distributive  lattice  is  a  lattice  in  which 

(Vz,  y,  z)z  A  (y  V  z)  =  (z  A  y)  V  (z  A  z). 

This  equation  states  that  A  distributes  over  V.  It  can  be  shown  that  A  distributes 
over  V  iff  V  distributes  over  A. 

An  element  z  in  a  lattice  X  is  a  least  element  if 

(Vy  €  L)x  <  y; 

it  is  a  greatest  element  if 

(Vy  €  L)y  <  z. 

Let  the  least  element  in  a  lattice  be  denoted  by  X,  and  the  greatest  element  by  T  (if 
they  exist). 

A  complemented  lattice  is  a  lattice  which  has  a  least  element  and  a  greatest  element, 
and  in  which 

(Vz  €  L){3y  G  L){x  Ay  =  X&  zVy  =  T). 

A  Boolean  algebra  is  a  complemented,  distributive  lattice. 

Any  powerset,  such  as  2^,  vdth  the  subset  ordering  C,  forms  a  power  set  algebra, 
which  is  a  Boolean  algebra.  In  the  power  set  algebra  2"*: 
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(V  x,  y  €  2"^)  I  A  J/  =  X  n  y, 

(Vx,y  €  2^)  X  V  y  =  xU  y, 

±  =  0, 

T  =  A. 

A. 1.4  Filters  and  Ideals 

A  subset  5  of  a  lattice  L  is  a  filter  if  the  following  conditions  hold: 

(Vx, y  G  S)x  Ay  €  S 

(Vx  €  5)(Vy  €  L)x  <  y  ^  y  S 

5^0. 

A  subset  5  of  a  lattice  L  is  an  ideal  if  the  following  conditions  hold: 

(Vx,y  €  5)x  V  y  e  5 

(Vx  €  5')(Vy  €  i^)y  <  a:  =*-.y  €  5 

T 

Let  L  be  a  lattice  or  semi-lattice,  and  let  x  be  an  element  in  L.  The  principal  ideal 
in  L  generated  by  x  is  the  subset 

{y  I  y  €  I  A  y  <  x}. 
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A. 2  Model-Theoretic  Semantics 


This  appendix  presents  a  very  brief  description  of  the  basic  semantic  definition  used  in 
model-theory.  Discussion  of  this  material  can  be  found  in  most  texts  on  logic  and  model 
theory,  e.g.  [3,  Ch.  2]. 

Consider  a  first  order  language  L  consisting  of  variable  symbols,  function  symbols 
(consider  constants  to  be  0-ary  functions),  predicate  symbols,  and  quantifiers.^  Consider 
a  model  for  this  language,  called  a  structure,  consisting  of  a  Universe  [/,  and  a  mapping 
from  each  n-ary  function  symbol  in  L  to  an  n-ary  operation  on  U,  and  from  each  n-ary 
predicate  symbol  in  L  to  an  n-ary  relation  on  U. 

A  valuation  is  a  structure  together  with  an  assignment  of  a  value  x'^  E  U  to  each 
variable  x.  Given  a  valuation  cr,  a  value  can  be  assigned  to  any  term  in  L  using  the 
following  rules: 


T  if 

±  otherwise 


3.(a  = 


T  if  =  T  and  /?<"  =  T 
±  otherwise 


4.(a  V/3)'" 


T  if  =  T  or  =  T 
±  otherwise 


I  T  if  a"  =  X 
1  ±  otherwise 


T  if  =  -L  or  =  T 

6.(a  i 

±  otherwise 

V 

This  definition  is  known  as  Tarski’s  truth  definition,  and  forms  the  basis  of  the  model- 
theoretic  semantics  of  first-order  logic. 

'For  the  purposes  of  this  thesis,  we  will  only  consider  quantifier-free  formula. 
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